>>Here is something that does NOT seem to be happening the way I recall it is supposed to happen: When an in-process COM server opens a DBF (for example, in its INIT method), I was told that the DBF is closed when that server object is destroyed, and that this happens regardless of what you explicitly code within the methods of the object. In other words, when you say in ASP: oMyVFPServer=Nothing, then the VFP COM object is destroyed and any open DBF's are by default closed within VFP's own internal cleanup mechanisms (even though your COM DLL itself stays loaded). That is apparently NOT what happens. My experience has been that if you don't explicitly close your tables within (for example) a DESTROY event, then they remain held open by the COM DLL even if NO instances of the COM object are in existence. What's the truth here? I'm not sure that I'm testing things correctly to arrive at this conclusion (but I think I am). Thanks!
>
>
>Are you sure there are no instances of the COM DLL? Remember that IIS will hold onto the DLL, which is why you need to kill the IIS Service to update the DLL.

Oh yes. the DLL remains loaded. But I thought that table access was scoped to each instance of a COM object created by the DLL (e.g, by using the server.createobject() call from ASP). I thought that when a given VFP COM object was destroyed, that its _entire_ datasession was also destroyed. I thought that the DLL nevertheless stayed loaded, serving as an "object factory", and when next called upon to instantiate an object, would create an entirely new global data session for that object. What's the truth?