>>How about a table on the server side that stores a record for each persisted piece of "state", with an ID identifying it for future use, and a MEMO field containing XML? Should perform pretty fast, especially with Rick Strahl's fast wwXML class to parse the XML in and out to a cursor.
>
>Wow, for each persisted piece of "state", a table could get real big real fast and then there are possible corruption / maintenance issues. From what I gather, the next version of SQL Server (Shilo) will address these concerns.

By piece of "state" I mean 1 record turned into XML, or a set of records if necessary, since XML can be hierarchical, all stored in one record's memo. You could recycle when done or timed out, but that could lead to memo field bloat if we're talking large numbers. Hmm, If you don't like that idea, then write the XML to disk STRTOFILE and remove it when you've signalled that you're done with that "session", with a cleanup routine to kill any leftover files on disk over a certain age.

>What about passing some sort of XML message back and forth between the client and biz objects.

That's fine for passing the data -- but we started out talking about *persisting* the data between calls to the biz object so you could identify which items were actually changed. How you plan to do that is the key question here. I guess you could get the data to the client side into a cursor, make changes, then go thru changed fields over on that side and only send the changed fields back as XML, which the biz/data object would update in the table. Is that what you meant? That would eliminate the need for server-side persistence for that particular situation right?

>>I quess it's time to take a hard look at XML. But then there is the problem of the emerging XML standards - not that it's a problem, but that I hate putting things on hold.

Again, at the risk of people thinking I'm on the WWPayroll :-) , I HIGHLY recommend Rick Strahl's book and the www.west-wind.com site with white papers, the downloadable wwXML class, and the downloadable Web Connection demo, and the great ideas in the Web Connection documentation (also look at wwHTTPData, wwSQL, and various other utility classes included with WC).

Rick is also an authority on XML standards and the bugs and limits in them (he even has methods to create badly formed XML so it can be read by ADO).