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.