InfoPath Dev

It is brilliant that Infopath automatically upgrades the form for you when you open it. Very often, though, this is not desired to be automatic. In an audited environment you want to keep a historical record of the form that was completed and approved. Using an example that perhaps everyone will understand, say a purchase order request once needed to be approved by two people, but now it needs to only be approved by one, so we change the template to reflect this. This doesn't change the fact that it is important to know the two people that approved all the old purchase orders. So ms. user is happily using the new template for current orders.. and now she wants to open one of the old orders to see what happened. What I want to know, is if anyone knows the easiest way to open an old form using the old version of the form template file and offer the user the option to upgrade the form to the newest version of the template. So that when the old infopathform.xml file is opened it looks the same as the day it was created. BUT if the user choses to upgrade it, it looks like today's latest template. I am assuming that it will be a programatic solution. I am currently thinking of investigating the sharepoint version control mechanism. Because the other option of having separate templates for each template version is not very elegant. ie polling a network directory for a template name that is newer than the one you are opening, eg when you open an old form from template_ver_1.xsn it polls the directory to see if there is a template_ver_2.xsn, and if there is, then trigger method xyz. Worst of all this means additional code to ensure that the users are saving the templates with the right name and in the right place, and now I have built a document management solution. If it is not a simple programming job, it ends up being just as efficient using Word templates with data islands for all your forms, which works really well if you are into lots of coding. :) Thanks Seamus

 Hi

Welcome to the forums.  I have got around this problem several times by just hiding the control in your example for all forms where the control is blank and not if the control is entered.  That way you can still view the old forms in completeness but new forms will only have one box, job done.

I hope this helps.

Cheers
 

Hi Seamus and welcome!

I like Adam's idea. I wouldn't do the hide/show on the control, though. Rather, I'd create a separate view for each version and add an Open rule to switch the the correct view based on the version in the form. You will need to save the version in the form's XML so that subsequent saves don't auto upgrade the view (unless they click the button to do it). The big drawback of this approach is that it only works for view changes (but that's probably all you need based on your post). If you need to upgrade the schema, this could work, but InfoPath always wants to update the schema to the latest version and you couldn't prevent that. If you are only adding nodes, however, that's not a big deal. If you need to change or delete nodes, then it wouldn't work. With many versions you could end up with a complex XSN, but I definitely recommend this approach overall since it is quite simple.

Another technique would to store each XSN as a separate version. If you are using just a Web server and have published the XSNs to a folder, you could do this but it would require that V1 knows of the existence of V2 (so that the "Upgrade" button knows which URL to add to the XML). Assuming the schema was upgradable (only additions are automatically supported) you just add some code opens using the new instance. There is a NewFromSolutionWithData method that you can use:

var objXMLNode = XDocument.DOM.selectSingleNode("/employees/employee");
var objXDoc = Application.XDocuments.NewFromSolutionWithData(objXMLNode, "C:\\Employee.xsn");

Note: you'll need to change the location (C:\\Employee.xsn) to be the new XSN on your share. Add a rule to close the existing after you call the code above. You'll probably want to mark it obsolete somehow or have the new form overwrite it - for that, you'll need to also pass the filename in the XML and set it in the new form (use OnLoad event).

For forms where the schema nodes either changed or were deleted, you can add some upgrade logic before the code above to to change the XML before opening with the new form.

If your form's schema didn't change, the upgrade should be quite simple - just call NewFromSolutionWithData and close the old form.

If you are using SharePoint and one form library for all of your forms, you can't easily do the above because form library supports only one form template. You could create multiple form libraries, but that would become a UI mess and code mess. If you absolutely need to continue with your existing SharePoint form library, I recommend storing the forms in SQL and replacing your default view with a data view that shows the forms stored in SQL. You can use a Web Service to manage submitting and retrieving from the SQL DB. This would allow support for multiple XSNs and it would be more performant than SharePoint for large form libraries. It would also allow you to do fine grained permissions and richer reporting. We provide a Web Service to assist so you don't have to write it from scratch. This would allow you to use the same technique as described above on an existing SharePoint site.

Hope this helps!

 

 

This works really well assuming 2 things.

1. We only ever add nodes to a form and never remove. Because I am just going to grab the root node and move the whole lot across as I don't want to write new code for each template change. (if we remove, we just remove from the view, not the xml)

2.  We have a mechanism for polling the share directory for the newest file. (Not very elegant, and easy for a non technical form admin to stuff up)

Neither of these issues are all that bad, and we can build some further functions to make it more seemless. But I do feel like I am missing out, especially on the first point, when I have a normal template and remove a node, infopath happily opens the old document sans the removed node... like magic :) Perhaps I need to bite the bullet and rewrite the infopath upgrade process..

 Seamus 

 

 

 

Hi Seamus,

My second suggestion of using SQL doesn't have the limitations you mention. Let me know if you want a demo. We have this working today.

The problem with rewriting the upgrade process is that it would probably not be generic. Automatic upgrade is really hard to get right.

Best!

 

 Thanks.

For the time being, we are going to use the "more production support" option. However, we'll want to revisit the SQL component you are describing in the future.

Seamus 

Hi Seamus,

Sounds good! Please let me know if you'd like a demo in the next two weeks. I will be on my sabbatical from 2/21 through 4/21. In my absence, please contact Clay for assistance.

Best,

Hi,

I used the method above "NewFromSolutionWithData", but the added nodes/controls on the new template weren't added to the new form.  I am missing somthing?

Thanks!