VFP is single-threaded, meaning that when it call a COM (DLL or EXE), it will wait that the method finish before processing the next line of code. You may acheive some sort of multithreading by RUNning a stand alone EXE (not a DCOM), but how will you get the result? How will you communicate with it once it is started?

I agree with you that the server should not wait until a query has finished before processing the next, because it may cause a bottleneck if many requests come in at the same time. To acheive this, you need a multithreaded tool which VFP is not.

A solution would be to build a communication layer that accept new connections and start a new thread for each connection. That thread will then call your VFP COM to do it's stuff and return the result to the client. You may have guessed that this communication layer is not written in VFP. It should be written with a multithreaded tool like C++ or any .NET language (yes, even VB.NET).

HTH

>I have a "server" application that receives requests from a number of clients, runs SQL queries or calls remote COM+ objects and then returns the results (currently the queue uses folders and files to communicate but I am switching to IPSocket)
>
>I want to avoid the "server" actioning one long query and ignoring the rest of the queue, I thought about either using "out of process" COM objects for each action in the queue or just calling an .EXE with a parameter EG. RUN /N action.exe /Query2 /Param1 /Param2
>
>The COM object gives me a pointer to the application but I have had bad experience with DCOM, is COM going to work better? Am I over complicating things?