InfoPath 2010

Re: Changing the structure of an existing InfoPath 2010 form

GedCT — Thu, 13 Oct 2011 11:58:33 GMT

Fantastic, thank you for that. Should save me lots of time and effort ...

Re: Changing the structure of an existing InfoPath 2010 form

Jimmy — Thu, 13 Oct 2011 11:13:04 GMT

This'll do. So what you can do for tblSelectionCriteria is remove 2 of the 3 tblSelectionCriteria mappings you have there, change the Node Path for that table to just . (dot), and then include all of the fields, including parent node names in the node path for each of the fields, e.g.:

ImagingExclusions - my:EXCLUSIONCRITERIA/my:UnsuitableForMRI
LackOfCapacity - my:EXCLUSIONCRITERIA/my:LackOfCapacityForConsent
...
CapableOfUnderstanding - my:INCLUSIONCRITERIA/my:CapableOfInformedConsent
...
Comments - my:INFORMEDCONSENT/my:DeviationComments
...

That should allow you to accomplish the kind of mapping you're describing without rearranging your data source.

Re: Changing the structure of an existing InfoPath 2010 form

GedCT — Thu, 13 Oct 2011 10:43:49 GMT

I've included mapping of the relevant areas of the InfoPath form to database or did you want the whole thing, as it's around 150 to 200 fields or so?

Re: Changing the structure of an existing InfoPath 2010 form

Jimmy — Thu, 13 Oct 2011 10:26:36 GMT

Thanks for the additional info. Could you attach a screenshot of your DB mapping with all the details expanded?

Re: Changing the structure of an existing InfoPath 2010 form

GedCT — Thu, 13 Oct 2011 10:08:41 GMT

I've included a screenshot of the current schema which has a nested repeating element in there for collecting the actual consent form signed and associated date information.

Essentially, I want the repeating element in it's own group and the non-repeating ones in a group together. The repeating group shreds into a different SQL table. I've used the migration tool before for backing up and restoring forms, but have encountered problems when trying to migrate data between forms and not found the time yet to go back through that properly; taking another look tomorrow all being well so that I can pull together a game plan for getting this resolved.

Re: Changing the structure of an existing InfoPath 2010 form

Jimmy — Thu, 13 Oct 2011 09:31:56 GMT

Hello Ged,

It is possible to do what you're describing. As you may be aware, moving around groups and things in your XSN can quickly cause existing XML documents to not open in it. To remedy this, our Migration Tool provides a feature to run your DBXL documents, in bulk, through an XSLT, which you can design to transform your old XML format into the new one.

This is a rather advanced topic though. Do your Inclusion Information, Exclusion, and Summary groups involve repeating data, or is it non-repeating? If it's non-repeating, there's most likely a way to arrange your DB mapping so that the data shreds into single rows instead of 3 separate rows.

Changing the structure of an existing InfoPath 2010 form

GedCT — Thu, 13 Oct 2011 09:00:35 GMT

I wasn't sure where to post this, as I think it's more related to InfoPath than DBXL, so please forgive me if it's in the wrong forum. Okay. I developed a form early on in my learning curve that I now want to amend to merge some of the groups that I used on the InfoPath form. Take, for example, inclusion criteria for a research study - I currently have one group for the inclusion information, one group for the exclusion and one group for the summary where all three shred into the same SQL table. As a result, I end up with three partial rows per study time point instead of one complete row.

Now, what I'm thinking is this! I think that I should be able to take the existing XSN file and re-order the groups so that they all merge into one SelectionCriteria group. Then, for existing XML files based on the previous template I just need to restructure the XML so that the structure of the XML file now matches the new XSN file. If I subseqently publish the XSN and load it into DBXL and redo the mappings then the XML file should shred into a single complete row within the table.

Is my logic correct, bearing in mind the potential problems this could introduce?