Changing a form schema without destroying the views - InfoPath Dev

InfoPath Dev

Use our Google Custom Search for best site search results.

Changing a form schema without destroying the views

Last post 07-23-2010 10:12 AM by chris leate. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • 07-21-2010 06:27 AM

    Changing a form schema without destroying the views

     I often have to make schema changes to existing forms. Every time I do this the view needs to be rebuilt even if the published form fields don't change. I keep getting told that the guy before me had a way of doing this without destroying and rebuilding the library views. I've had a good old search on this and I can't work out how he did it.

     Are there any good articles on this? It looks to me like the indexed columns are given IDs dependant upon their position in the schema and that these generate the fields in WSS_Content. Changing anything major always seems to result in rebuilding every view and a certain amount of down time while I rebuild all the views.


  • 07-21-2010 06:29 AM In reply to

    Re: Changing a form schema without destroying the views

     The only thing I can think of incidentally is writing a custom upgrade script each time to handle stuff. But I can't see any evidence that he actually did this.

  • 07-22-2010 09:35 AM In reply to

    Re: Changing a form schema without destroying the views

    Well I worked out how he did it. I'd still like to know how others do it. The developer before me created loads of additional fields called field1 field2 etc and used these to store any additional form variables that he needed to add so that the schema didn't alter. This doesn't make my life any easier but at least I know why there are about 10 unlabeled fields in all these forms. If there is a way of maintaning up time for views that is more graceful then please let me know about it.

  • 07-22-2010 02:31 PM In reply to

    Re: Changing a form schema without destroying the views

    Key thing is to only add fields that are non-required. Don't delete or rename nodes or add nodes that are required.

    Getting the schema right at the beginning is really important. Having field1, field2, etc. is a very bad practice because people have no way of knowing what the field is for and when you start submitting your data to a database and have to do mapping, it is really hard to keep track of all fo the field1s.

    We have a Doc Migration tool that migrate forms from one schema to another. You can even use this tool for free to batch migate hundreds or thousands of forms. Just install the free trial of DBXL. Get the Doc Migration tool. Add your XSN template to DBXL. Import all your XML files. Read Jimmy's blog on how to create XSLT mapping files. Create the upgrade XSLT. Setup a new XSN with the new schema. Run Doc Migration from old to new. Export all the XML from the tool. Presto!


    Patrick Halstead
    Project Manager at Qdabra
  • 07-23-2010 10:12 AM In reply to

    Re: Changing a form schema without destroying the views

    Thanks Patrick, that's something that they don't tell you in the books. I'd already released a new schema with a required field on when you replied but I've now managed to get it all back up and running again. Because the relink documents function was broken for the new schema I had to programmatically move the forms to a new library and then move them back again programmatically using workflow. This was a pain. I'll check out your app sounds like it's what I've been writing console apps for for all my failed updates.

    How do you go about validating the repeating sections without making them required? Do you usually have a code behind or xpath conditional formatting thing going on on the submit button or something? Or do you write a code behind in c#?

Page 1 of 1 (5 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.