The issues I was having with the commit had to do with that the user wasn’t changing the field so the dvwp didn’t want to save the row. You might say that is correct — nothing to save if the user hasn’t changed it. Well, I was changing the values of some of the fields as the form loaded — prepopulating some of the answers with what we had stored in another database. Business rules needed to keep the question on the form, even though we knew the answer.

So, if I loop through the fields and append a space to the end, the dvwp thinks the field has changed and it saves it. The dvwp in multi-item edit mode doesn’t save the data if nothing changed since the last page load.

Also, make sure you’re updating the right control. Some controls (People Picker, Date Picker, for example) have one control for display, but the data-bound control is actually hidden on the page. (Another example would be a select with over 20 options.) So, you might be changing the display, but not the data-bound control.

If you find the right control, the OK or Save button should commit the data in that control.

Blessings,
Jim Bob

I’m also trying to fill in some default values on one of my forms, but the data isn’t being saved. I think this is because when the form loads and the user hits save the row hasn’t changed.

I still need the row to be saved, I’m just pre-populating the data thru the query string, it’s persistant due to validation/postback issues, or it’s pre-populated thru the select statement.

Mr Florian has a pretty good description here: http://social.msdn.microsoft.com/forums/en-US/sharepointcustomization/thread/80712782-36fd-42d2-9c12-dd54768efa87

So, your cascading drop-downs work becuase there still some user interaction on that row.

If I could find out a different option for the ASP TextChanged, like ForceSave or AlwaysSave it would work. But I can’t find one.