InfoPath Dev

What I observed is that removing all the secondary repeater groups before removing the primary repeater group seems to fix the issue. It's annoying, but it's a functional workaround... Thanks for taking time to look into this Hilary! I always appreciate your help.

Hilary; not sure I fully catch your drift - would you mind uploading a modified version of the template? I greatly appreciate your help. I tried creating another group under the root and then moved the "Primary_Repeater" group into it, but it didn't seem to make a difference. I may not have understood your instructions. Also, if I ...

Attached is a sample XML file that can be used to preview the form. Delete the "Primary Repeater Section 2" group and see that the "Repeater Aggregate Stage 3" field does not update.

Here is an example template that demonstrates the problem. Enter values into the fields highlighted green, adding as many fields, field groups or primary groups as you like. You'll note that all field values are aggregated into large double eval expressions. The problem is that the high level double evals do not update when an entire ...

After deleting a repeating section on my InfoPath form and submitting the form back to the site, the published column still contains all the data that used to exist in the form.  The column is created by a double eval based on the repeating section. The fields in the form display correctly, but after saving the form the XML file ...

The attached XML file can be used by going to "File>Form Options>Preview" and browsing to it. This file is very minimal and contains only the information needed to invoke the error.

I have a form template that throws a "number of calculations for a single action exceeded the maximum limit" error while opening. The error must be invoked using a particular set of sample data which will be attached. I narrowed the problem down to the following node/field through trial and error and also by removing nodes from ...

A simple example of this conundrum is as follows: When entering a default value into a data field one can enter "../my:value1" - the relative location of that value to the current field. When entering this same field into a filter the field is specified as such "xdXDocument:get-DOM()/my:myFields/my:MasterSection/my:value1". ...

Wilkies, Thanks! My problem is that I have something like 400 fields with default values, many of which are in repeating sections. The logic inspector is handy, but it doesn't tell me which rule is erroring out. Perhaps I am using it incorrectly however... Just haven't been able to single out the issue with the logic inspector yet.

Is there any way to identify the particular field that is throwing an error message? Can it be done without the trial-by-error method of changing and deleting things on copies of the template? I seem to be stuck trying to delete half of the template at a time but I can never pin down the exact field that is causing the problem. I believe ...