I've done some testing, and have found .
one rule that prevents the postbacks . . .
I have static fields at the top of my form for name, job number, etc. I have a repeating table (insert/delete disabled) for users to enter expense information. They click a save button after each entry to save this info to SharePoint (and sets it to Saved status). I have another repeating table to pull data back from Sharepoint, and display conditionally on status.
My "Job Picker" drop down list has 7 rules applied to it -
-Delete expense table (qrules) - deletes the expense table whenever a job is selected.
- Insert blank row (qrules) - inserts a new, blank row of the expense table
- Propogate fields - propogates other fields, such as job location, start and end dates, etc.
- Delete Saved Purchases (qrules) - deletes the repeating table bound to the SharePoint list (showing saved or other expenses depending on status)
- Set Query Fields - Sets the SharePoint query fields to filter on Employee and Job Number
- Query List - Queries the Expense List on SharePoint.
- Copy Table (qrules) - copies the SharePoint Table into my main data source.
In the Expense Table (user input), I have an option button to display either picture control or file attachment depending on what user picks. This needs to ALWAYS post back. I also have a checkbox to allow user to set a status to "Pending", and a rule will set that status when a user clicks save.
Now, when a user picks a job that has no previous data saved for that job, the postbacks work fine. If the user picks a job that HAS previously saved data, the postbacks STOP working. If I disable the last rule (CopyTable), the postbacks work no matter what job is picked.
Why the heck would this happen? Why is this table being affected by CopyTable, which is bound to a completely different table?