>>Hi Jim. I pulled some articles about using VFP for Remote Automation. In the examples, they assume you want to use the automation server with products other than VFP, so they use long character strings to transfer records. These strings will then be parsed and used by the client.
>>
>>If we assume that the automation server will only be used by VFP clients, and therefore VFP tables will be readable by the client, do you know how record sets can be passed back to the client in VFP table format?
>>
>>Thanks.
>
>Joseph,
>
>Passing a record set back to the client by any means other than ADO/RDO is of questionable value in building middle tier objects. The whol;e reason for middle tier objects is to separate the data from the interface by providing a middle layer that handles requests from the interface and delivers data from the backend. The nature of the data should be insultated from the itnerface such that the interface only deals with the middle tier object. The interface should have no idea how the data is gotten ro in what format it exists.
>
>To get the table style of data you asked about I would use RDO or ADO to the middle tier.

Sorry for my ignorance, but I'm not sure what ADO/RDO means. Hey, excuse me, I have code to write; not enough time to learn :) .

I want to step back for a second and bore you with a few details: Basically when our users pay claims, the system has to adjudicate the claims which requires pulling-up a claims history for the individual and his/her family. I thought that if we see a reduction in network traffic, we might see some speed increase. So when I heard "remote automation", I thought this might be the answer. If the server only sent back the neccessary record sets (the claims history of that particular person), I would assume network traffic would be reduced. Does this sound like a good reason to use remote automation?

I want to also add that we are quite happy with the way things are right now; VFP pulls this stuff up quite fast. But, faster is better.

ADO/RDO?