>Terry,
>
I can see you are determined about using foxisapi! ;-)
>
Let's just say it's a time management issue:)

When instances of your server app are instantiated via ISAPI, they do remain active as a process that should show up in Task Manager on the server.
I checked with some bread and butter VFP projects - it seems the runtime space is include with a desktop project EXE's space.

Theoretically the instance is supposed to close again after a defined period of inactivity. From memory, there is an ini file setting for FOXISAPI that lets you have more than one instance simultaneously that will share the load.
Thanks for reminding. The INI file is something I need to look at. Ricks paper helped some in that regard - but it seemed to be related more to foxWeb. I am sure there are settings that will prove beneficial.
>
Re performance- it can be hard to tell on a local machine, but generally COM is better than file-based on a server, not least because because file-based has to check 100 times/sec to see if another "hit" file has appeared. Your app is always working away and there will always be a small latency, unlike COM where it sits quiescent unless it receives a hit.

The exe VFP COM/ foxISAPI seem crispy fast. It's (by orders of magnitude) noticably faster than JSP under Apache. I have not yet got to the point where I am ready to build and test as DLL (or MTDLL). From what I have read, the DLL will be superfast. I also located some info by Calvin Hsia. He goes into "critical" section management with SYS(2336) pool management and datasessions. He also discussed (but I need to read more) how to kill threads when a particular connection has issues.

It was my first read of that kind of detail.

Now if I could just figure out a way to prevent foxISAPI writing those ini files. All the info the transaction needs is in "cFormvars". But maybe that happens with any type of IIS connection.

And speaking of connections, when will we be able to connect to an object. Instanciation is such a hog!: