>Correct. COM servers can only access VFP environment stuff through objects you might have passed it.
>
>Ask your self this question though: if your COM server were to rely on data open in the VFP environment, why is it a COM server at all? The purpose for COM is get cross-platform compatibility. If you are calling your COM srever from VFP, and the COM server was written in VFP to only work with a VFP client, why the heck is it a COM server and not just a class?
>
>You are not the first person to ask this question on this forum, but the fact that it is getting asked worries me that many people are miunderstanding the purpose of COM. We should not be building COM server for the sake of building COM servers. If your only client for your server is VFP an the source for the server was VFP, you shouldn't be leaving the VFP environment to do this work. There is no use using a the Windows mechanism for object brokering when the objects are internally native in the first place. Trying to do this just makes implementation awkward, and greatly degrades performance as far as object instanciation times.

Actually, I was just trying to test it. I'd written it as a class within VFP and wanted to see how it worked as a DLL.

But it've learned something important here... two com servers on my (future) middle tier can't reference the same cursor without first opening it themselves.

Better to learn this now then 3 months from now.

paul