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.
>
>I think this is just like in the file/server arena. Each client has their own "environment" which stores all kinds of things such as variables, forms loaded into memory (with their properties and methods etc), workspaces open with which tables, on which records with which filters etc. None of this can be shared between clients as it exists in an unshareable memory assigned to the client. To share info between clients it must be written to disk (ie to a table).
>
>I'm not sure I understand what your concerns are with VFP as the server. All this is determined by VFP the client.