Todd,

In the case I am contemplating, which really is my first attempt at 2-tier or 3-tier (if carried further) design, the Clients will do all of the UI stuff but the *single* Server will provide *ALL* database updates to the VFP databases.

So the Clients will, early in their code, CREATEOBJECT of the Server program. This, according to OLE (and proper EXE building and WIN Registry entries) will cause the active (pre-started) Server program on the appropriate machine to be "connected" via OLE.

As the Clients need service from the Server, they will invoke Methods *of the CREATEOBJECTed object* (server) to perform the necessary function. The Method executed will return parameters, probably mainly in arrays, when it is finished. And so it will go, until the Client user signs off, at which point the Server will be Released.

What I worry about is (my terminology) COLLISIONS of the parameters from the various Clients IN THE SERVER.

I have a personal purpose, in addition to the usual reasons, for pursuing this approach - I am very disappointed with VFP's OBJECT ability vis-a-vis table information. This way I can preserve all the goodies like RI, triggers, etc and yet I can code the UI parts with "better" objects than would otherwise be the case.

Regards,
Jim N.

>>>
>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.