InfoPath 2010 reporting overview
Learn what options you have when it comes to reporting, creating reports for, and analyzing data that is stored in InfoPath 2010 forms.
There may be times when you want to create reports for the data that is stored in one or more InfoPath forms. And while InfoPath is not a reporting tool, you can combine it with other applications to create reports.
Typically, reporting scenarios include displaying data from one or from multiple forms. An easy way to display data from multiple forms in a report is by first merging the forms (using the merge functionality in InfoPath) and then creating a report for the main form that represents all of the forms that were merged together.
However, before you can merge forms, you must create a form template with merging as forethought, not afterthought. So if you know in advance that you will want to combine data from multiple InfoPath forms for reporting purposes, you must design the InfoPath form template that is used to create those InfoPath forms in a way that the data can easily be merged afterwards.
Once you know which data on which InfoPath form(s) you want to use in report(s), it is time to choose an appropriate application to create the reports. For this you could use a reporting-specific application such as for example Crystal Reports, or you could use applications from the existing suite of Microsoft applications such as for example Access, SQL Server, or Excel.
Database applications such as Access and SQL Server tend to have their own reporting tools built into them. But to be able to use such applications, you would first have to import the InfoPath form(s) for which you want to create reports into one or more tables in a database before you can create the reports.
In an article entitled Import data from InfoPath into an Access table, which is available in the InfoPath 2010 Cookbook Club, I already showed you how you can import data (including data from a repeating table) from an InfoPath form into Access, thereby splitting the data to be stored in one or more database tables. You can use this same solution in InfoPath 2013 with Access 2013 and extend it by writing code to bulk import multiple InfoPath forms into an Access 2013 database.
And in an article entitled Import InfoPath XML into SQL Server, which is available in the InfoPath 2010 Cookbook 3 Club, I already showed you how you can import data from InfoPath forms into SQL Server using SQL Server Integration Services (SSIS).
Once you have imported InfoPath data into a database, it is then a matter or knowing how to create reports in the respective applications to display the data on the reports.
There may be times when you don’t want to create fancy reports, but rather analyze InfoPath data in an application such as Excel. As far as Excel goes, you can import InfoPath data into an Excel workbook manually, programmatically, or (without writing code) through Excel Services in SharePoint Server 2010.
MSDN and Office Online offer enough information on how to get this done. And an
upcoming InfoPath 2010 with Excel and Excel Services book of mine should provide you with enough examples on how to get this done, if you don’t want to spend a couple of hours doing the research yourself.
So in summary: You can use the merge functionality in InfoPath to create a main form that combines the data from multiple forms into one form for a report, or if you want to take reporting a step further, import InfoPath form data into other applications such as Access, SQL Server, or Excel to create fancy reports or analyze data.
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.