Erik,

The way I understand DCOM is that object is actually instantiated at the client's machine. This scenario would be much slower. Please correct me if I am wrong.

>DCOM, or HTTP?
>
>
Does this mean the form can be set to private datasessions and MTS will handle the rest?

>For truly stateless objects (those hosted in MTS that participate in transactions), it doesn't really matter: since your environment is set up for you on every method call, you can't stomp on other sessions even if they were shared.
>

>For configurations where state does matter, and you need to confirm that each instance uses its own DS, base your components on the new lightweight Session class, and just make sure that its DataSession property is set to 2 for private datasessions.
>

I would think that xml would be faster for sending data over the wire, but again I might be wrong. What's the advantage of using one method over another?

>That depends on how you are transferring your data in the first place. If you are using DCOM, you can pass an ADO recordset from tier to tier, and use that to do your updates. If you are using HTTP with XML or some other manual method, you can either build your server to accept and execute a dynamically built SQL statement, receive a delimited list of values, or accept and parse data sent back in an XML document. Since I use XML between tiers, my updates are sent on the form of a complete or partial record representation in the same XML format that was retrieved. The server, on reception of the document, parses, and applies updates as needed.
>
That makes sence to me.

>Conflicts can be handled using a timestamp on the set of data originally received. At the time of update, a comparison can be made between the server data's current timestamp, and the timestamp that was retreived with the data at the time of the initial query. A difference in timestamp can be handled with your method of choice (Last user wins, last user loses, last user decides, etc).