Microsoft InfoPath Lessons Learned

Microsoft InfoPath is a solid tool for creating customized forms to collect data, especially when integrated with SharePoint. Creating the form is simple through a WYSIWYG editor and a largely drag and drop process. The word “simple” applies only to creating the form. It typically becomes complicated as soon as the form is published (or attempted to be published). The form will start throwing weird errors with incomprehensible messages. If you do manage to publish the form, then it will exhibit strange behaviors or unexpected results.

Although Microsoft announced that InfoPath would be discontinued on January 31, 2014, I’m still using it to create new forms and thought I would share some lessons learned.

A duplicate field name “<field name>” was found

You have just created a fancy new InfoPath form and you attempt to publish it. Everything seems ready to go and then InfoPath displays the following error message:

A duplicate field name "<field name>" was found

Others have posted workarounds that involve editing list definitions within the .CAB file. I wasn’t able to try these methods with my limited access to the server and effectively no administrative permissions.

In my case, the SharePoint site had a few global site columns defined which were used in a number of different lists. I was able to create and publish InfoPath forms for those other lists without an issue. However, this one particular list kept throwing the duplicate field name error.

The solution that worked in this instance was to create a new list column. I transferred the existing data from the site column to the newly created column. Once the data was copied, I deleted the site column from the list. I was able to leave the site column definition available in the site settings for the other lists that were working fine. I was then able to update the InfoPath form with the new column and publish without error. Unfortunately, the list used a number of site columns so I had to repeat the process for each site column in the list.

InfoPath Form Refreshes on Every Change in Field Focus

This behavior appears to happen in InfoPath forms with secondary data sources. Each time a form field loses focus, a postback is executed and the form refreshes. This creates a delay for the user and a noticeable screen flicker. For fields that do not need a postback, I have found that changing the “Browser forms” properties of the field to never send data will eliminate the problem. Using the REST web service API instead of connecting to an external SharePoint library or list as your secondary data connection seems to have a positive effect as well.

Long Running Script Warning in Internet Explorer

With InfoPath forms using a secondary data source to connect to an external SharePoint library or list, I have experienced errors in Internet Explorer when the user attempts to save the data. The browser will display the following warning message:

Stop running this script? A script on this page is causing your web browser to run slowly. If it continues to run, your computer might become unresponsive.

This happens consistently if the secondary data source is returning a large number of rows. As best as I can tell, the save action initiates a postback which triggers a refresh on the secondary data source. The time needed by Internet Explorer to parse and process the data will cause the “Stop running this script” warning message. This behavior appears to be limited only to certain versions of Internet Explorer. Firefox, Chrome, and other browsers behaved as expected and without incident.

As a workaround, a REST web service data source can be used instead of the connection to a SharePoint library or list. For a reason unknown to me, the postback and data source refresh for REST data sources does not occur when the form data is saved.

State Service Error Occurred While Processing Your Request

The InfoPath form has been published and users are now able to begin saving data. The form has been thoroughly tested and it is working perfectly…

…until the first non-test user attempts to save data and the following error is displayed:

This error message apparently means that the user does not have permission to enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces. The user will either need to be assigned to a permission level that has this permission selected or it needs to be activated on one of the existing permission levels.

Using the SharePoint REST Web Service

SharePoint sites have a REST web service available through listdata.svc.It is accessible by calling the following URL (obviously adjust the parts in between <> for your particular site and remove the <> characters):

https://<site address>/_vti_bin/listdata.svc/<list name>

To return only a subset of columns in the list:

https://<site address>/_vti_bin/listdata.svc/<list name>?$select=<Column 1 Name>,<Column 2 Name>

To sort the data in a particular way:

https://<site address>/_vti_bin/listdata.svc/<list name>?$select=<Column 1 Name>,<Column 2 Name>&$orderby=<Column 1 Name>

To filter the data:

https://<site address>/_vti_bin/listdata.svc/<list name>?$select=<Column 1 Name>,<Column 2 Name>&$orderby=<Column 1 Name>&$filter=<Column 3 Name> eq 'XYZ' and substringof(<Column Name 5>, trim('<     ABC     >')) eq true

In this last example, I am filtering <Column 3 Name> to only return rows where it is equal to the string “XYZ” and where <Column Name 5> contains the substring “ABC” with leading and trailing whitespace removed. There are a number of functions and conditions available to filter data.

Creating a Rule to Change the REST URL in InfoPath

One of the actions available in InfoPath is “Change REST URL”. This is a nice feature because it allows for dynamic filtering of data returned from your external data source. Using the above example for filtering data using listdata.svc , you can create a formula in the action using concatenation and field data entered by the user in the form. As an example, a series of cascading select lists can be created using this method.

concat("https://<site address>/_vti_bin/listdata.svc/<list name>?$select=<Column 1 Name>,<Column 2 Name>&$orderby=<Column 1 Name>&$filter=<Column 3 Name> eq '", <Field Name 1>, "' and substringof(<Column Name 5>, trim('", <Field Name 7>, "')) eq true")

Add a second action to query using a data connection and the filtered results will be returned.

Detecting Changes on Multiple Selection Checkbox Fields

Rules and actions associated with changes to multiple selection checkbox fields do not behave as I would expect. A multiple selection checkbox field is a single field that contains multiple data values that can each be individually checked or unchecked. A rule set up with a condition to execute when the field changes will trigger as expected when items are checked. However, if a checked item is unchecked, the action will not be triggered.

In this example, assume the multiple selection checkbox field is called Products.

• Create a text box field called “hidden_field”. This field does not need to be visible on the form.
• On the field properties for hidden_field, set the “Default Value” to the Products field and check the “Refresh value when formula is recalculated” field.
• On the field properties for Products, create a new rule that is triggered when the field is changed. Add an action to set hidden_field’s value equal to the Products field’s value.

Once these rules are set, checking or unchecking values in the Products field will result in the value of hidden_field changing. Since hidden_field is a standard text box and rules are triggered as expected on a text box, we can then create additional rules using hidden_field to execute based on changes.