Seeking assistance with my Project (which I thought was going to be very easy....) - InfoPath Dev
in

InfoPath Dev

Seeking assistance with my Project (which I thought was going to be very easy....)

Last post 01-17-2011 05:49 AM by BZ6DJS. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 01-16-2011 03:11 PM

    • BZ6DJS
    • Not Ranked
      Male
    • Joined on 01-07-2011
    • Ottawa, Canada
    • Posts 11

    Seeking assistance with my Project (which I thought was going to be very easy....)

    Hi Guys, I am back. What I thought was going to be a relatively straight forward project has now thrown several curves at me and I am feeling a little overwhelmed at the moment. I am new to the forum so please forgive me if I posted in the wrong area. A bit of background: I use an XP Pro workstation. I have Site Admin access to a SharePoint 2007 Team Site (which we do not wish to save the data on because of costs to use up space on the server). I have Access to an external SQL 2005 server through the Team who supports it and they are willing to work with me (they are SQL Admins) and I believe Admins on the Server as well. I am not sure how receptive they will be to installing software on their SQL Server...

    This is how I thought my project would work. Our Team would like to collect surveys - I put together a form in InfoPath that allows people to type in text. I wanted to store that text in an SQL table. There is a 2nd view to my form because a manager would like to review the text and make their comments on what was put into the form and contact the client if need be. That is it!  Absolutlely no requirement to do any database manipulation etc - no calculations, nothing else - put the text in a table and allow the manager to review it should that be necessary. I would also like to be able to E-mail the form to some Team members so they know it was submitted. So in my infinite wisdom I thought "OK Easy Enough!" - InfoPath has access to SQL great - build the form, place it somewhere on my Team Site so people can access it as a web page, >>>> the client would go to a link and form would pop up in browser -->> they would fill in the text and submit -->> form would dump the text to a table in SQL and email someone so they know it was submitted. Done!

    So first I find out  that the SQL interface is not great from InfoPath, and that I might need a web service. In pursuing that I was pointed at Qdabra, so I pulled down QRules not really understanding it may not be the product I need. After some reading I think perhaps I need DBXL .... After more reading I find I can't run it on my XP workstation to build my form.. not sure where it needs to be installed as the SQL server is external and I have no real access to it and the SharePoint env is not available to me as mentioned above... I feel completely lost at this point....  If I am not planning to do any manipulation through my form on the SQL table, and only want text in the table ... do I really need all this?

    I am brand new to InfoPath to start with.. so felt really good about having created the form!!  But am a lot overwhelmed about all the other choices there are. Can I just put the form on my TeamSite so people can open it from a link? Do I really need a Web Service to put text in a table on SQL? Or do I need Qrules? I feel I am trying to take on more than I know how to do at the moment. I do hope to grow into this and hopefully someone can assist with the basics so I can get an understanding of just what I need for what I thought would be a very simple project.... If I do need the Web Service where would it need to be installed in order for people to be able to click submit on their form and have the data go to the SQL server? Do I require DBXL or Qrules? Any assistance would be much appreciated.

  • 01-16-2011 08:19 PM In reply to

    Re: Seeking assistance with my Project (which I thought was going to be very easy....)

    Sorry to start this off with a downer, but I think what you've experienced here is the fact that InfoPath really is easy to use for creating a form quickly without any experience, but actually integrating it and making it available to people while having environmental limitations is not easy at all.  Many of us do this for a living, and it's the knowledge to overcome these things that make us valuable.  What I mean by that is you can't just expect to pick it up overnight.  If someone gave you this assignment without specifying the tools and giving you full access to those tools, then you were set up for failure.  That is my opinion.  However, your mission can be accomplished with InfoPath, but I have a ton of questions that must first be answered:

    1. What do you mean by "costs to use up space on the server" when referring to not using SharePoint?  Why do you have to worry about costs for storing very, very small XML files?  If you can't even submit small documents to SharePoint, then that's kind of ridiculous.  Can you please clarify (not necessarily from you to me but the SharePoint team to you) why there is such a limitation here?  SharePoint doesn't store data on "the server."  It uses SQL Server, which is why the statement is confusing to me, because the whole rest of your post was talking about using some other SQL server to store text from these forms that live in SharePoint.  One way or another, you're going to use SQL server, which SHOULD be attached to a Storage Area Network (SAN), which stores everything from all your SQL Servers, whether related to SharePoint or not.  Do you by chance have a hosted SharePoint environment or something?
    2. How are your clients able to access your site to begin with?  You said you're the site admin for a team site, but then this form is for clients?  It's unusual for external people to be able to browse right into your internal SharePoint environment.  Is this an Internet-facing site?  Is your company completely open to the Internet and exposing its SharePoint environment freely?  How do clients log in?  What account do they use?  Are they given Active Directory accounts, or are you using FBA?  If using FBA, how do they log in to the same site as you?  Is the web application extended to allow FBA on the extended site?  Do they access different web front ends, or the same ones?  Is there a firewall device between them and the WFEs (i.e. ISA/TMG)?  Do they log in to a custom ASPX form or through ISA?
    3. Is this a MOSS 2007 Enterprise farm?  That is the only version of SharePoint 2007 that supports InfoPath browser forms.
    4. When using browser forms, you cannot submit directly to a database, which is why you need web services.  If you have an Enterprise farm and are definitely using a browser form, then you really should just let the forms submit to SharePoin - that is EXTREMELY easy and simple.  If you have to go with this external SQL solution, then it's going to be much, much tougher.  Do you know how to write web services, or is someone going to develop them for you? 
      • To use web services, you'll have to have a web server that can host the web service (can be the SharePoint WFE or some other machine).
      • Then, you'll have to create a Single Sign-On account in Central Admin that uses the credentials of an account that has write access to your DB table through the web service.
      • Next, you'll have to create a submit data connection in the form for submitting data to the web service, and then you'll have to convert it (inside InfoPath) to a UDC, which requires a Data Connection Library in SharePoint.
      • After converting the DC to a UDCX file, you'll need to manually edit the UDCX file in Notepad and tell it to utilize the SSO account you created above.
      • Make sure the InfoPath Forms Services settings in Central Admin allow for cross-domain access.
    5. It would be easy to notify people after submission if the form was actually being submitted to SharePOint, because you could then build a simple SharePoint Designer 2007 workflow (free product) that automatically sends email notifications to each specified user with a hyperlink to the form in the email body.  If you don't do this, then you have to add "submit to email" data connections in the form, which actually submit the form itself to those users through email (either the active view only or the whole form by attaching the form template).  I prefer workflow.
    6. You don't need qRules nor DBXL to do this, however, your limitations may put you in a place where you need DBXL.  It is an incredible tool, but do you have a budget for 3rd-party products when you can't use up a tiny amount of space in SharePoint?  That's the real head-scratcher.
  • 01-17-2011 05:49 AM In reply to

    • BZ6DJS
    • Not Ranked
      Male
    • Joined on 01-07-2011
    • Ottawa, Canada
    • Posts 11

    Re: Seeking assistance with my Project (which I thought was going to be very easy....)

    Thank You! I do appreciate what you have gone through to make your living... and appreciating more each day. Let me say that perhaps I set myself up for failure by taking on the project. That aside.... I own the project and will do my best to take it forward. Here are the best answers I can provide.
    1. The SharePoint env that we use has been in place for many years and has been used mainly for document storage to date. In fact the storage of our Team Procedures etc has used up the space allocated to us such that we have received messages to clean up our space - which was accomplished through archiving and document clean up. My Team pays for a chunk of space for our Team Site which is very close to full and we have been asked to be "concientious" about what gets stored on the server so as not to fill up the remaining space. For this reason, I thought I could put my form on the site and have people link to it - then save the data to an "external" SQL server that my Team has access to outside of SharePoint. Not knowing all the intricacies of putting a form on the Team Site, I was thinking it would be 1 page and minimal space usage...
    2. All of our "clients" are within our company. We are like an escalation Team that people can come to with problems that they cannot resolve. Not open to the Internet at all. On our Enterprise Team Site we have one Site open to the "internal public" of the company that people can use to find our phone numbers and forms to open tickets with our Team (which is another form I had hoped to create and store on the Team site - on this one its email only though) and a form to send in a survey. All of our current forms are Word documents and I was hoping to bring us forward and use a web based form in place of making people open - update - email a word document. One of my tasks as a Team Member is to look after both sites (internal and public) of our SharePoint env. When we get emails about space in use we clean up. By using the web forms I had hoped to eliminate Excel sheets, Word Documents etc and free up more space - not to mention lessen the aggravation of having to work with a word document to open a ticket or submit a survey.
    3. Yes we are using Enterprise MOSS 2k7. We have a SharePoint Team who administer the servers (I am not a part of that Team but only given access to my Team Site).

    4. WOW.... all I can say about these points... and no... I do not currently have skills to be able to do that.

    5. I have looked at SPD 2k7 and workflows and ensured that I do have that option in SharePoint.
    6. Hence my email asking if I really needed to have these tools. No budget at all for this. But, what I can tell you is that I will go back to my Manager and suggest we submit the form and keep the data within the SharePoint env. Knowing the difference in the costs between using some space and budgeting for 3rd Party Products should convince them that using a little space is the better option.

    I wish to Thank You for taking the time to reply and provide some guidance. I believe I will push to have the info stored in SharePoint and stay away from the external SQL server. Your assistance is MOST appreciated.

Page 1 of 1 (3 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.