Rick,

I guess I didn't emphasize I was talking only about the speed of the CALL to the server. And that's only significant if you are making lots of calls per second. The server I'm working on can handle peak loads of about 500 calls/second most of that limitation appears to be related to table writes and PK generation because each call causes a record to be written. This is about 5 times faster than the expected peak load and about 20 times higher than the steady state load.

It's also kind of interesting that my VFP test driver for the server has nearly the same performance as the VC++ test driver.

>>If the server needs to have a UI it has to be out-of-proc. If you don't need a UI it can be either one. Calls to an in-proc DLL server are about twice as fast as calls to an out-of-proc EXE server in my testing.
>
>You have to be careful how you phrase that.
>
>DLL servers aren't any faster than EXE servers - it's the only
>the call interface that's faster. IOW, the code all runs at the same
>speed - only the parameter passing is much, much slower with OutOfProc
>servers (as much 500-1000 times slower) under *ideal* conditions!
>
>Things is, if you have a procedure that runs a query that takes
>20 seconds and returns there's not going to be a noticable difference
>between InProc and OutOfProc. If you have a routine that calls the
>VFP server in a tight loop with small chunks of data you'll notice
>the difference like night and day.
>
>I've tested operation of InProc and OutOfProc servers with Web
>Connection using its pool thread manager and the difference between
>InProc and OutOfProc is marginal - the main reason is that each request
>is a single method call to the server, but even with 15-20,000 hits an hour testing under load there was only a 2-5% difference.