Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
COM
Message
From
20/04/2000 16:08:18
 
 
General information
Forum:
Visual FoxPro
Category:
Client/server
Title:
Re: COM
Miscellaneous
Thread ID:
00362014
Message ID:
00362027
Views:
19
>Maybe you all can help me out here. I just joined a new company that is shipping an international VFP application worldwide. They are keeping the data on a server in New York as well as the middle tier (COM objects). The interface is VFP.

DCOM, or HTTP?


>My challenge is to create COM objects to talk to the backend (SQL Server and VFP), convert the data to XML and send the data to the client (VFP) over the internet. How would private data sessions be handled?

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.

>For that matter, since the client can't talk to the data directly because the middleware will exist as stateless components, what's the best way to handle updates?

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.

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).
Erik Moore
Clientelligence
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform