InfoPath Dev

I have a situation (fairly long explaination) where I need to pull many values from one form onto another. The first form (a) is sparsly populated, the second is fully populated. To save time having to retype entries from form B into form A I was hoping there would be an automated solution.

I briefly looked into merging, turned it on, and it seems to add form B as another record below original form A record. I didn't go any further than that because I was hoping it would fill in the existing record with form B values.

Any suggestions?

Hi George,

Sounds like you're talking about the often-requested "template" feature. If the forms are the same and you want to use one as "sample data", we call that request the "template" feature because you use the data from one as a template for others.

Merging is definitely meant to do this and much more (it will even help you import forms of a different schema - i.e. form A is different from form B - and that enables kind of forms-based workflow client-side). So, it's a very cool feature but, unfortunately, it requires XSL if your form has repeating sections.

In InfoPath 2003, the Status Report form had a merge xsl - look at that for an example of how to merge one into another when there are repeaters. You'll have to save the source files and look at the manfiest - search for importParameters. It will refer to an XSL file that controls the merge sequence. Very powerful, but hard to debug. Two other samples that shipped in IP2003 also demonstrate A-B merge - look at Issue Tracking and Meeting Request (start with the latter).

Finally, we have a taskpane tool (called qForm) that we developed for customer which has built in template logic (but requires the schema to be the same, i.e. it isn't a replacement for merge/aggregation). Let me know if you'd like to see a demo.

Also, let me know if you need help with the merge XSL. We can help you here too.

Related post: http://www.infopathdev.com/forums/p/7061/25888.aspx#25888

I'm very confident that webservices will fix this issue that we are experiencing, and we are planning on implementing soon. Until then I have these forms that did not submit. 

Here is the scenario:

The user opens a new form and fills in 4 of the required fields, and then through code the form submits to SQL, runs a stored procedure against that new record, then requeries SQL for the updated record.

The user then saves the xml form locally for a day or two while they wait for more information. They open the form back up, fill in the rest of the data, and submit. this is where the submit seems to fail from time to time.

The problem now is that those forms that failed will continually fail. SO we have to find a way to update the SQL records (the ones with only 4 fields of data filled in) with the failed form data.

Unless I can figure out another way soon I might have to resort to reentering the failed forms by hand  :(  something like below.

Print out the form that the user filled in, requery SQL for the existing record using a new infopath form, then reenter (by hand) all the new data that was collected, then submit.

I'll keep trying other routes, maybe coding, but that sounds painful. I'll update this thread if I get something working.

Hi George,

Based on my analysis yesterday, I don't think this is an ado dataset diffgram issue. It's likely some network protocol issue as you suggested in your 4:22pm private e-mail. Nevertheless, you don't have to resort to manually entering. Just save, open in Notepad, delete the xdadoset element at the bottom. Save. Reopen in InfoPath and submit. This will create a new record with the new data. That isn't exactly what you want, but you can delete the old record and it will save you some time over manual.

Good luck!

Patrick,

Thanks for the information. 

We have run a few scenarios and this is what we found. Anyone can edit the form but the catch seems to be that, the computer that ran the stored procedure originally, is the computer that has to run the submit. On top of that, if it is submitted from a different pc that particular forms submit seems to be broken after that.

In order to get the broken forms back into the database, we WILL be using merging. I have to admit I'm a noob with infopath/sharepoint and it's just my luck I get to learn as I go with a fairly complex workflow. Last night I figured out all the options for merging which is very cool indeed for getting the broken forms back into the database. I am in the process of automating this if the form fails to submit.

-George