I think you misunderstood me. When I said that the COM server opening a table and making it available to the client is bad, I meant that making it available to the client as in a table open in a work area (it's a good thing that this can't be done, because open tables are a Fox concept, and not a server concept).

I didn't mean that COM servers shouldn't open and use tables, and pass data and even objects back to the client, only that ALL interaction between server and client needs to be through the server's PEMs.


>I don't necessary agree with your conclusion about COM and tables. You can still have your COM objects open tables, manipulate them and still maintain client independence. They will need to pass the fields or records by PEMs or by returning an ADO recordset to the client and the client must be ready to work that way also. Sharing datasession with a COM is a no-no.
>
>>But if you are only using these classes from VFP, then they don't need to be COM srevers at all. You can still get all of the code reuses with a regular VFP class, and none of the overhead of COM.
>>
>>Having a COM server open a table and making htat table available to the client goes against the spirit of COM, which is supposed to be client independent. All communication with the COM server should be through its PEMs- no tables, no global variables, nothing else.