Problem with Administrator Approved Forms Promotional Field / SharePoint Column Update - InfoPath Dev
in

InfoPath Dev

Use our Google Custom Search for best site search results.

Problem with Administrator Approved Forms Promotional Field / SharePoint Column Update

Last post 02-25-2013 12:21 AM by dbfuller. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • 02-24-2013 07:23 AM

    Problem with Administrator Approved Forms Promotional Field / SharePoint Column Update

    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
  • 02-24-2013 12:15 PM In reply to

    Re: Problem with Administrator Approved Forms Promotional Field / SharePoint Column Update

    Hi David,

    The column ID issues are vexing. I was talking to another person at the SharePoint User Group last Thursday and she was having the same issues. We have solved this countless times, and I think we even have tools that admins can run to fix site columns. I need to check with the guy that deals with this more often. We will plan a weekly webinar in the next month to describe the issue in depth and list up the workarounds.

    In the meantime, may I suggest a different approach? We tend to use SQL for these kind of scalable solutions. When the values are stored in a central SQL table, you don't have to go through the shenanigans of mapping promoted properties. It's easy to do with our DBXL Web service. Just create a mapping and submit. Then, when the forms open they can query the database through the Web service. These URLs are automatically fixed up when they are published to a new server which saves you the trouble of having to content type deploy.

    Best,

    Patrick

    Patrick Halstead
    Project Manager at Qdabra
  • 02-25-2013 12:21 AM In reply to

    Re: Problem with Administrator Approved Forms Promotional Field / SharePoint Column Update

    Thanks Patrick for the reply. (I was only just watching one of your videos yesterday!) Vexing is definitely the right word for this problem. If have more info on the tools or a documented solution that would be a great help. I have thought about your alternative solution before. It seems the logical way to go in accessing central data from a large scale deployment, however there are drawbacks to this. 1 - the user(s) can't maintain their own info. E.g. a contacts list/library. 2 - extra management of documents that reside in a site. I.e. mirroring the sites libraries and the movement/creations documents within them. 3 - authentication would need to be built so that one site collection could not see an others info. Again, if you do have anything or know anyone that could help me with this that would be a massive help. Thanks, David
Page 1 of 1 (3 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.