Hi Rick,

>No, this isn't right... Tables close when the object is destroyed in all
>situations. Even if you're not using a Session object.

I guess my comparison to a desktop application wasn't the best one <g> COM objects are created in an instance of VFP. This instance is bound to the lifetime of all objects instantiated in that instance. If the last object is destroyed, the instance is shut down and all tables are closed. As long as there's one object still alive, the instance remains loaded and tables stay open.

>Try this in an MTDLL:

Compiled it to test.test. What I meant is the following. Even though o1 is released in between, the table remains open because o2 keeps the instance in memory.

o1 = CreateObject("test.test")
? o1.TableTest()
o2 = CreateObject("test.test")
o1 = null
o1 = CreateObject("test.test")
? o1.TableTest()

Of course, this is a simplified scenario, because VFP as a host doesn't load the MTDLL into multiple threads or does weird things with caching DLLs as ASP does.

>Well, the point is moot since tables can't stay open across calls. There's no point in closing tables if you're using MTDLLs from ASP/ASP.NET since they don't persist.

What are you doing differently than I am? I copied the test.dll created from your code into \inetpub\scripts and registered it. I also created a webcounters.dbf file in \Windows\System32, because that's where DLL tries to open the file. Then I create the following test.ASP:

<%
  Set oRef = createobject("test.test")
  Response.Write( oRef.TableTest() )
  Set oRef = Nothing
%>

The first time I call the page I get "Opened table". Then I hit F5 and get "Table already open". This is on Windows XP SP2 with ASP being pretty much in the default configuration.

I always interpreted this as ASP keeping object references around to keep the DLL in memory and releasing it at the most inappropriate moment. That is, the instance might stay in memory (thereby keeping all tables open) or not, ASP might reuse an existing instance or create a new one in an available worker thread. That's something that ASP seems to control,not the COM developer.