The backstory:
- We are using Admin' Approved Forms to central deploy the same form to many different site collections.
- We have about 4-6 different forms per site, each with it's own form library. For example, two of these forms and form libraries are Purchase Orders and Bookings.
- A typical function of these forms is to display another form library as a data source. For example, within the Bookings form a list of PO numbers is displayed from the Purchase Orders Library.
- We are using data source files, which we replicate on each site and then manually update the list GUID and site url. This allows us to use the exact same set of forms on many site collections.
- The above is carried out on one (the default) site to first (this is the same site that is used when initially publishing the forms and creating data source connections to the form libraries).
- The field promotions are set up as normal for each form and then the form is published and then activated to the first site. The field promotions are obviously a necessity if they are going to be used as data sources in other forms.
- Before activating any form on a second site, any field promotions have to be changed from the original "create new column in this library" to the now existing field (column) within the "Microsoft InfoPath" group. Essentially the form's field is being mapped to its self.
- After the form is republished for second time, the internal column id (on the activated site's column, site content type and list content type) is updated to include 'x007b' ({) at the start and (you guessed it!) 'x007d' (}) at the end. Now when forms are activated to another site collection, the columns are created from the form's template/content type. This means that columns will use same internal id (with 'x007b_ at the start and...) on every site collection ...and makes it possible to use "relative" data sources and data source files.
The problem:
The problem with all the above occurs when a form's field promotion setting is left using "create new column in this library" and then activated to another site collection. At that point there will be a column on each site with the same name but completely different internal id's. Now any data source using this column on the second site won't display any data and any querying on that column throws a nice error to the end user. The obvious way to remedy this situation (which i have tried) is to change the fields promotion setting from "create new column in..." to "Microsoft InfoPath" existing column. Obviously that doesn't work. As the column has already been created on the second site (with a different ID (GUID) to the first) they will always be different. Interestingly though, the second site's columns internal id updates with (with 'x007b_' at the start and...) BUT the first site's column stays the same (no '_x007b_' at the start and...).
While investigating all of this, I noticed that maybe the problem was furthered by the first site's list content type not updating while the site's content type was being updated.
Another characteristic of Admin' Approved Forms, which makes it hard to recover from this problem, is that i can't remove the content type or columns after deactivation.
If you do mange to read this all then thanks for taking the time. It's always hard to explain these thing so if your totally lost then let me know and i will have a rethink on my description.
Hopefully you might recognise this situation and might have experienced it yourself. One idea to eradicate all of this would be to rethink my solution for scalable (reusable) "relative" SharePoint list datasources. Any thoughts on this will be much appreciated.
Thanks, David Fuller