Hi Christof,
>> >- When a USE command is executed within a method of a MTDLL COM object, does the "used" table remain open even after the object is destroyed?
>
>Yes, just like in a desktop application.
No, this isn't right... Tables close when the object is destroyed in all
situations. Even if you're not using a Session object.
Try this in an MTDLL:
FUNCTION TableTest
IF !USED("WebCounters")
USE WebCounters IN 0
RETURN "Opened table"
ENDIF
RETURN "Table already open"
ENDFUNC
even from VFP and call a couple of times, then delete the object reference.
Tables do remain open across method calls of course. A COM object instance is in a way a real instance of VFP so as long as that instance is alive everything stays open. Kill it and everything closes.
This is one of the big performance bottlenecks of MTDLLs in a Web environment or at least in a Microsoft Web environment because ASP.NET and ASP both load COM objects on a per page basis and then release them. A smart thread manager might keep those objects around. I think AFP does this sort of thing as does Web Connection which provides the ability to provide some internal state to COM servers.
>That's a matter of performance and maintenance. Keeping files open independent from the object increases performance and resource usage. Normally, that the good thing. On the other side of the coin, though, keeping files open makes maintenance more difficult. You have to stop the application in order to gain exclusive access to the tables even if you know that nobody will access your web application for that time.
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.
THe EXCLUSIVE issue doesn't go away even if you do close everything because with pure MTDLL and ASP/ASP.NET you have no control over the process (IIS/ASP/ASP.NET) to tell it - hold on a sec i need to do maintenance. Again, this is something where a custom implementation like AFP or Web Connection can provide value because those tools know about Visual FoxPro and it's uhm unique needs for data access (memory buffered data, Exclusive access requirements etc.)