Bill,

>I could be wrong here...
>In mmTextBox.StateChangeHandler code reads:
>
>case (mmBusinessState.Bind):
> this.OnBindData(bizObj, e, this.IsPostBack);

Gotcha...you're right...if I change "this.IsPostBack" to "false", then binding is independent of whether you're posting back or not (which it should be), and depends only on the state of the business object (which it should). I made this change for persisting data in Beta 10 (the parameter is set to "true") and THOUGHT I had done so for data retrieval. ANYWAY, I'm making this change to all Web controls and it will be in the next release.

>Understood. I was hoping for a suggestion. I'm not only concerned with expiration, but having 2 browsers open editing the same table to copy/paste, etc. If it's stored on anything that references only the session it won't work. Almost need to generate a unique id, store it in a hidden field, and use it to reference the proper instance of the dataset. Maybe give up the whole DiffGram concept and use the suggestion of retrieving a new dataset and updating. Possibly storing a record version or timestamp in a hidden field and comparing it inside a transaction during the update to be sure of no concurrency violations.

Have you checked out the Cache object? I highly recommend the article "Nine options for Managing Persistent User State in Your ASP.NET Application" in MSDN magazine:

http://msdn.microsoft.com/msdnmag/issues/03/04/aspnetuserstate/

Regards,