A browser-enabled InfoPath form was to be built that allowed users to fill out a form, email it to themselves, attach a document to be uploaded to SharePoint, and then sent to an individual that understands SharePoint. Sure, the easy answer here is to make the user upload the file directly and just classify it there. The problem is that many users are unwilling to be trained on SharePoint, so this was elected as a compromise to fully utilizing SharePoint. There’s some other border-cases that this form solves, but this is neither here nor there.
The form has a number of drop-downs in it, some are SharePoint ‘choice’ fields, and two are SharePoint ‘lookup’ fields. The choice fields all function just fine since I’m using a nice little XML file to specify those dropdowns (they rarely change and it’s much quicker to load than querying all of the lists). The lookup lists do need to be refreshed on each form load, since those are subject to additions. However, InfoPath Browser forms have a nasty habit of ordering SharePoint-list-data source values by ID rather than Title. [To add further insult to injury, the full-blown InfoPath client orders by Title..] Users wouldn’t go for that on lists that contain upwards of 500 choices, so I had to find a way to order by Title…
After reading some great articles on using owssvr.dll to get a XML output for a particular list, I figured I had the problem licked. This method would allow me to return live data (on form-load), required no code-behind, and seemed straight-forward. So I followed the instructions (http://blogs.msdn.com/b/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx), and then pressed enter to get a plain-white IE window (no XML as promised). After verifying that this wasn’t some obscure browser setting, I looked at the lists I was referencing and they were (both) custom lists that also had lookup columns contained within. I then suspected that the lookup column (especially one that allowed multi-select) wasn’t supported by the owssvr.dll method. Luckily for me, we are running a nifty little master-list data synchronization on this environment. The custom code basically reads a list (considered the ‘master’) on Web Application A, Site Collection A, and then writes any add/update/delete actions to copy-lists stored other Site Collections under Web Application B. Anyways, the ‘synchronized’ lists don’t contain the lookup columns, just the ‘ID’ and ‘Title’ values. Effectively, this allowed me to test owssvr.dll reading a ‘simple’ list…
After running a quick test, I discovered that owssvr.dll worked famously with the sync-lists! So, I rebuilt my form data connections, redeployed the form, and then BAM! Yet another error about SharePoint not being able to access data sources [Error ID 6932](and all of my dropdowns of lookup lists were blank). After some poking around, I surmised that InfoPath form services (even with cross-domain enabled) doesn’t like crossing SharePoint web applications, even though the user account I was using had permissions to both web applications.
So, to get the form to play nice, I simply deployed my form and associated data sources in a site under Web Application B. By doing this, my owssvr.dll XML files could reference the appropriate sync-lists correctly and in the same web application. After I did this, the form worked as advertised and I simply changed all of the applicable links to point to the new form location.
I realize that this is a fairly unique scenario, but I think there are a couple of important takeaways. First of all, for users that are running into the blank-white IE screen when using owssvr.dll, hopefully this post helps you in your test cases by trying the method after removing lookup columns. And Second, for those who might be considering/trying to get InfoPath Browser Forms to cross web applications, realize that you may have to somehow provide a simplified version of your list-data.
At the end of the day, the form worked as advertised, and the correct columns were returned (and ordered).