InfoPath has limitations for advanced forms that require repeating sections, reporting on data, and integrating with external databases. Moving data to a SQL database addresses these issues and enables enterprise-level functionality like centralized data storage, improved reporting, and faster queries. A data-driven web service approach allows InfoPath forms to securely submit and query data from any SQL database without requiring custom code or changes to the database schema. All form templates can leverage a single shared service.

1. Moving Beyond InfoPath
SELECTING A BETTER E-FORMS TOOL

2. The Problem

So you have moved beyond the simple InfoPath forms into advanced
tasks like:

Have repeating sections within forms with parent, child, even grandchild
relationships

Want to report on InfoPath data using tools like SSRS

Want to leverage existing databases/web services for creating rich composite
forms

3. What are the options?

Out-of-box approach - create form from SQL database

Customer Code - extend your existing form with custom code

Common Library (Rules) - use one set of rules for all forms

Business Connectivity Services - connect external data systems

Custom Web Service - middle-tier service-oriented architecture

4. Obvious Choice – Submit Data to SQL
Server

SharePoint lists/libraries don't scale

Document permissions (ACLs) peter out at 5,000 items

View performance degredation after 10,000 items

SharePoint protocol (DAV) is slow

Limited reporting options


Export to Excel is two dimensional, Performance Point is hard to figure out
Relational databases (SQL) enable enterprise scenarios

Central data in one place

Easier to: backup, replicate, repurpose across sites, migrate, integrate with other systems, etc.

Reporting: build dynamic reports with Reporting Services

Performance: filtered queries are faster through SOAP

5. Out-of-box Database Template

Cons


Doesn't work in a browser (because of double hop authentication issue)

Limited data types - must conform to SQL data types


Can't use with existing forms
Schema change requires down time
Pros

Works out-of-box

6. Out-of-box Database Template

7. Out-of-box Templates

8. Custom Code in the Form

Cons

Developer required and browser support requires admin deploy

Tightly coupled solution cannot be reused for other InfoPath templates

Brittle - breaks easily when database schema changes

Expensive - downtime when form datasource changes

Not Best Practice - SQL command cannot be parameterized

Security risk - however, developer can easily "escape" fields to prevent SQL injection


Pros

Works with existing databases

Does not require deploying a web service

9. Common Library

Code required for advanced operations

Copying, sorting tables

Converting images to links

Integrating with lists

Submitting to a SQL database

Code will be hardcoded to schema of form

Writing code requires a developer

Maintaining separate DLLs is costly

10. What is a common library?

No developer required

Inject library in form template

Use commands via rules

Data-driven commands

Same library for all templates

Less cost to deploy and maintain

11. Business Connectivity Services

Cons


Doesn't support repeating data

Doesn't support certain data types (for ex: bigint)

Stored procedures needed for query performance (to reduce result sets)

CRUD XML is complex


Authentication configuration required
Adding fields requires lots of wizard time to reconfigure and doesn't update list editor
(i.e. you have to create a new list)
Pros

Works with existing databases

Provides list-based editing for data

12. Custom Web Service

Cons


Parameters most likely hardcoded to form template

Web service must be deployed


Developer required
Proliferation of Web services complicates
migration
Pros

No code in form

No code in DB

Fast queries

13. Data-driven Web Service

All InfoPath templates use the same web service

All query shapes use the same web service

SQL to XML mapping defined in dynamic query
string

Web methods take XML data to query SQL tables

User impersonation means SQL permissions
can be defined to lock down users

14. qDabra Data-driven Web Service
(DBXL)

Cons



Web service must be deployed to server
More work to configure with existing databases
Pros

Single web service supports all form templates

Works with existing forms

No code in form, no code in DB

Fast submits (and queries)

No downtime when schema changes

Less cost to deploy and maintain