InfoPath Dev

 Hi

 I have a strange problem with copying SharePoint list values to a repeating section in a browser form. I'm copying individual fields rather than using copy table and the form works fine in InfoPath 2010, but when I deploy the form to SharePoint only the first record in the list is copied to the repeating section. I've done this before on other forms and it's worked fine and the only difference with this form is that another repeated section is nested inside the one I'm having problems with.

 

Has anyone encountered this before?

Thanks

 

Neil Elliker

Hi Neil,

So if I understand the scenario correctly, you're doing something similar to this:

http://www.infopathdev.com/files/folders/qrules/entry58577.aspx

And this is working fine in Filler / Preview, but failing to work as expected in the browser.

Can you attach a screenshot (via the Options tab) of your form schema, showing the nested repeating tables? I would imagine that this is not the issue - that is, if it's working in Filler and not Browser, perhaps there's some other issue at play (not the schema). But, I can try to reproduce the scenario locally and let you know what I find.

You could also attach the form itself, or screenshots of your list, or anything else relevant to the scenario. When replying just look for the Options tab. Thanks.

 Hi

 Yes I'm doing exactly as in the link.Here is the schema, sorry I couldn't get all of the fields in the picture.

 

Thanks

 Neil Elliker

 

Hi - I think since this is working for you in Preview but failing in IPFS the most likely culprit is event bubbling. Changes in your nested group are likely causing rules on the parent group to fire again.

In these cases, I usually add some helper fields for rule conditions - normally to a secondary XML file data source. The first rule on my nested group will be to set my helper field to 1, for example. The final rule on my nested group will be to set my helper field back to blank. On the parent group, I add a condition to only execute those rules if helper is not equal to 1. So, when the rules on my parent fire, they insert rows to my child group. My child group sets the helper field to 1 to keep the insert (or delete, as the case may be) rules from firing again. Does this make sense?

In the test Ernesto set up, there were rules on a field inside the parent repeating group to execute a query, and those were executing when a row was inserted in the browser, so I needed yet another rule condition to prevent that - in our test case, I simply added a condition to not execute rules on that field if it were blank, but your scenario may be different.

Usually when I am tracking down these things I start disabling rules from the inside out - It helps me figure out where my rules are misfiring.

Hi Hillary

 Thanks for this. I've got this to the point where it now inserts the correct number of lines but it only inserts one of the IDs from the Sharepoint list and leaves the other line blank. So it seems to be going wrong on page 14 of the documentation for doing this. This form differs from the example in the documentation in that the data source is not a straightforward SharePoint list connection, it's using an xml data connection instead as I needed to filter it by a value in the form that the user chooses so I'm not sure if this makes a difference or not.

Thanks

Neil 

Can you either attach your form under the Options tab or send to me via Support AT Qdabra DOT com (and reference this thread). I can take a look and see what may be going wrong for you.

 Hi

 I've attached the form.

 Thanks

Neil Elliker

Which ID field? - that is, are you talking about the ID in the Journal group? Or the DetailID?

 Its the one called idNumber in the details repeating section.

Okay - and just to be certain I understand - all this works correctly in Preview? But in the browser, only the first instance of IdNumber is populated?

EDITED: I am asking because looking at your form, it doesn't seem like event bubbling would come into play here - you aren't inserting any nodes on the inner group, for example, that I might expect to see cause the logic to fire again. One thing you may want to do is add a field you can use to keep track of what's changing - verify that the counter is the value you expect when you expect it to be and so forth - just set the value of the field to itself concatenated w/ the latest value, so you have kind of a running list of information.