InfoPath Q&A: Where is InfoPath form data stored?
Learn how and where you can store InfoPath forms and what the difference is between InfoPath forms and ASP.NET forms.
I’ve seen the following question pop up several times in the log files of my web site:
Where is InfoPath form data stored?
So I’ve decided to attempt to answer it. I say "attempt", because unfortunately, there isn’t one definitive answer to this question. InfoPath forms can be stored wherever you want to store them.
Saving vs. submitting InfoPath forms
If we are talking about submitting InfoPath forms, you can submit an InfoPath form to:
- A web service. In this case the web service decides what to do with the data it gets from the InfoPath form. The InfoPath form is not stored anywhere.
- A document library on a SharePoint site. The InfoPath form is stored as an XML file in a SharePoint form library, where the data will wind up in a SharePoint content database.
- As an e-mail message. In this case, you can optionally attach the form as an XML file to the email message. The form is not stored anywhere, but sent in an email.
- To a hosting environment, such as an ASP.NET page or hosting application. In this case, the hosting environment decides what to do with the data it gets from the InfoPath form. The InfoPath form is not stored anywhere.
- To a database if you bind the Main data source of the InfoPath form template to a database. In this case, InfoPath form data is stored in corresponding database table fields.
But you can also just hit the Save button in InfoPath and save the InfoPath form locally on your computer or on a network share. In this case, an XML file is stored on disk or a network location.
The difference between saving and submitting an InfoPath form is not as clearcut as I would like it to be, but you can see
- saving an InfoPath form as putting an InfoPath form somewhere like for instance on disk or in a SharePoint document library (this action stores the data of the form as a physical XML file); and
- submitting an InfoPath form as sending the data that is in the InfoPath form somewhere like for instance in an email message or to a web service (this action does not necessarily store the data of the form as a physical XML file)
InfoPath forms vs. ASP.NET forms
The output of InfoPath is XML, that is, you create an XML file if you save a document from within InfoPath. InfoPath forms once saved become self-contained XML files, that is, they contain all of the data and information (link to a template, which contains the form’s data structure or schema, data connections, code to run, etc.) necessary to be used independently.
The main benefit of having an XML file is that you can easily share it between systems that can speak XML and know the structure (schema) of the XML file. So InfoPath is most useful in scenarios where you want to gather, store data in a file, and then share this data between systems.
Traditional ASP and ASP.NET forms have always written data to some storage location. This could be a text file, a database, or calling a web service that takes care of the storage. While it is possible to store ASP and ASP.NET forms as files, they are almost never stored as files. And there lies the main difference between InfoPath forms and ASP forms. InfoPath forms were designed to be stored as files, while ASP forms were not.
InfoPath and SharePoint
When InfoPath went from version 2003 to 2007, it became more integrated with SharePoint. InfoPath browser-enabled forms were introduced with InfoPath 2007 and SharePoint 2007.
And with using InfoPath forms within the browser in SharePoint and also as forms in SharePoint workflows, InfoPath started to move away from its initial design for gathering and storing data as XML files. While InfoPath browser forms can still be stored as XML files in SharePoint form libraries, they are more and more being used to replace traditional ASP.NET forms.
The main benefit of using InfoPath instead of ASP.NET is that InfoPath allows users to quickly put a form together (you can literally click a form together with all its rules and validations in place without writing a single line of code), so it is not surprising that more and more businesses are trying to replace existing ASP.NET forms with InfoPath forms.
For example, when InfoPath is used for instantiation and association forms in SharePoint workflows, the data entered in the form is only used in the workflow and not stored anywhere. So in such instances, InfoPath forms resemble ASP.NET forms where they are only used for gathering and then passing on the data entered.
To this extent, I wrote an article for the “unconventional use” of a browser-enabled InfoPath form for entering data and then using this data to create a custom list in SharePoint. While the XML for the InfoPath form could be stored in a SharePoint form library, for example for auditing purposes, the primary function of such a type of form is only to gather data and not store it in the form itself.
Copyright: This article may not be used on web sites (whether personal or otherwise), copied, disseminated, altered, printed, published, broadcasted, or reproduced in any way without an expressed written consent of S.Y.M. Wong-A-Ton. The techniques demonstrated in this article may be used within any Microsoft InfoPath project. This article is provided without any warranties. Copyright for this article is non-transferrable and remains with the author, S.Y.M. Wong-A-Ton.