Browser Forms

Re: Deleting a row in Repeating Table, Crashes Form

ErnestoM — Mon, 30 Jan 2012 13:44:34 GMT

Sounds like you have a lot of controls sending data back to the server (Postback settings = Always).

Try to reduce that number; if a postback is not necessary in a particular instance, it can slow down the performance of a form without adding any benefit. For example, if the value is just pulled in to a field, it's value changes from (blank) to a value, and it triggers a postback unnecessarily. If there are no rules, no conditional formatting, no validation, no code, nothing executing on that field, then the postback setting can be Never.

Re: Deleting a row in Repeating Table, Crashes Form

Michael Clark — Tue, 24 Jan 2012 15:39:12 GMT

Two fields referenced from the Item group into the Revision group.

"ITEM" = Part Number & "DESCRIPTION"

When I run design checker, It shows me warnings on 80 controls. Below is the most common type of warning.

_______________________________________________________________

By default this control will send data to the server whenever it's value changes.

Reason: it is bound to a field or group(/my:myFields/my:SalesData/my:FG-Data/my:Item) used in the following expression:../../../my:SalesData/my:FG-Data/my:BaseSaeItem[../my:Item = current()/..my:Item]

This can lead to effects that can be evaluated only on the server.

To override this behavior, modify Postback Settings on the Browser Forms tab of the Control Properties dialog box.

_______________________________________________

Is it possible this is related to the issue with deleting rows from a repeating table?

If I set the Browser Forms tab to NEVER for PostBack. Wouldn't that make the data local to that control?

Thanks

Re: Deleting a row in Repeating Table, Crashes Form

ErnestoM — Tue, 24 Jan 2012 15:31:54 GMT

How many columns in each of the two (linked) tables? (Items and Revision)

Re: Deleting a row in Repeating Table, Crashes Form

Michael Clark — Mon, 23 Jan 2012 20:21:36 GMT

Thanks for your reply,

My form is designed for Browser compatibility.

If I select Preview from the InfoPath design view, I can test the forms logic and functionality. The form works fine if I do that..

It is after I publish it to InfoPath From Services when I run into this issue.

I have many other repeating tables on the form. I have no issues with deleting a row out of them.

Fields in the problem group (ITEMS) are referenced into other groups.

i.e. Item & Description are referenced into the Revision Group. I can delete a row from the Revision Group which refereces fields in the Item group.

But

I can not delete a row from the Items group.

MRC

Re: Deleting a row in Repeating Table, Crashes Form

ErnestoM — Mon, 23 Jan 2012 13:58:04 GMT

So if you change the form library to open in the client, the form works fine? You mention that the form works in Preview, but it would be worth testing in the client.

Is it something that happens will all forms, or just this form? Perhaps there are too many rules and there is a performance issue?

Deleting a row in Repeating Table, Crashes Form

Michael Clark — Thu, 19 Jan 2012 14:46:23 GMT

Hello,

I have a rather large infopath application for processing Engineering Changes.

We use SharePoint 2007 with MOSS? I am publishing my form to Infopath form services.

There is one key repeating group in the data source for "ITEM" = Part Number.

This group tracks all the data about each part number involved in a change.

On the main view,

When a user Deletes a row from this repeating table, They receive an error from InfoPath Form Services that reads;

WARNING: There has been an error while processing the form.

The only two options is "Try Again" OR "Exit Form".

Try Again just keeps looping back to this error. Exit Form dumps them out.

I read posts here about the "Post Back" settings. So I set the fields inside the table to never. The table is set to only when necessary.

I have no scripts or code on the form. Just simple rules.

HELP! ! ??? ADVICE??

I should add. The form works fine in Preview Mode. Fails at the server.