>Todd,
>
>Perhaps *I* have mis-understood what a VFP Application Server is, so let me take a bit of time to give my impression in hopes that you will spot the error of my ways (or you will spot *my* problem). . .
>
>Typically a non-UI type of program, a VFP Application Server is a single VFP application running on a machine and acting in a service capacity to several VFP client applications running on other machines.
>The Application Server and the Clients are "closely related" in that they each perform specific work towards an objective for each client operator.
>
>So a VFP Application Automation Server is much like any other VFP program with the exception that it does *not* perform UI-type functions, but rather uses Properties and Methods and parameters supplied with Methods invokations to perform specific work, dependent on the Method, for the Client. It will return responses to VFP Application Clients typically through return code and parameters (originally passed *to* tthe Method).
>
>Each Client is a single instance. BUT the VFP Application Automation Server is a SINGLE INSTANCE too. Now EACH Client is coming to this SINGLE instance to request some service. Furthermore, these requests for service arrive randomly and, often, as simultaneously as they possibly can.
>
>These Clients could all request the SAME METHOD, the only real difference being the parameters they pass to specify the particularities of what exactly they want. Remember, this Method that I am talking about IS IN THE SERVER, not in the Client. So the "environment" which worries me is the Server's - HOW DOES THE PARAMETER (SET) FOR Client "A" *NOT* GET CORRUPTED BY THE IMMEDIATELY ARRIVING PARAMETER (SET) FROM Client "B" AND FROM Client "C"??? Yes, those parameters all started out IN THEIR OWN MACHINES, BUT THEY END UP IN THE SERVER'S SOLE MACHINE TO BE ACTED UPON.
>
>If I have the WRONG idea as to what a VFP Application Automation Server is, or how one might operate, PLEASE tell me so.
>>
No you are correct, this will be the behavior. But aren't the UI forms being run by the client, and thus the methods and properties on the client side. Strikes me as a design issue. Some methods and properties that are data related (such as those dealing with referential integrity etc) should be on the server side, but the UI forms should be on the client side. Actually can be a nice balance, using server side data for cross user items and client side data for within user items.