Here’s a brief summary of InfoPath gaps in SharePoint and SQL integration for out-of-box solutions (assumes no code added to InfoPath form nor SharePoint):

• SharePoint limitations
  • SharePoint views cannot be configured to show repeating data from an XML form.
  • Document level permissions – you can manually set permissions in SharePoint for documents, but controlling permissions based on document level fields cannot be done.
  • SharePoint list view performance degrades after ~3000 forms. This is a known limitation in SharePoint. Not a limitation if the data is in SQL. Workarounds include:
    • Archive forms so you have <3000 active. Not a solution if you need to see all of them.
    • Restrict views to show very few forms and enable paging. Once again, can’t see all forms.
    • Submit forms to a separate database via a Web Service and use BDC Web part with filtering and paging to quickly view data
  • Submit performance is slower (~4x slower) going to SharePoint than to a Web Service. Click here for more details.
  • No support to search for users in Active Directory or SharePoint user list. Call GetUserProfile to set user, but can’t check for group membership or get other Active Directory properties.
  • No dynamic filtering for SharePoint lists – populating dropdowns pull all data down from the SharePoint list leading to slow form load times. Filtering via OWSSVR is hardcoded (not dynamic).
  • Number of columns limited to fixed numbers. Using Web Service with SQL and BDC solves this scenario.
  • SharePoint out-of-box search does not support wildcard searches for forms (details). You can’t search for App* and find both Apple and Application..


• SQL Database integration issues
  • No database support for forms created first using XML. Requires total rewrite.
  If you create a form from a database first, you would have the following limitations:
  • Adding fields to data source don’t show up in new SQL columns. You’d have to add to SQL first and then convert your main data source. Previous XML data would not migrate forward.
  • Changes to DB schema will invalidate previously saved XML files in SharePoint.
  • Images, rich text, and other non-SQL data types cannot be saved to SQL. Must be saved in XML but then you have migration issues per previous two bullets.
  • No server-side dynamic filtering when populating dropdown values with SQL queries. If the SQL table is large, it could take a very long time and time out.
  • No locking of data submitted to SQL – multiple writes could happen if two people open the same form. Last writer wins.
  • No dynamic role-based permissions – you have to add users and/or groups to SQL manually and specify READER or WRITER. Can’t dynamically determine reader and writer based on field value.


• Without SQL, you have Reporting Issues
  • Reporting would be flat – repeating data cannot be aggregated in a report. You would need to move the data to a database or create an XML query tool on top of your XML files which would likely be a solution specific to one XSN, i.e. schema-dependent not general.
  • Export to Excel not supported for more than one repeating section and not feasible for more than 10-20 XMLs at a time.

Qdabra’s DBXL Web Service fills all of the above gaps.