>This setup works fine and the speed is acceptable considering most of the data transfers occurs on weekends and at night. However, we are about to implement this for additional datasets (VFP, at least 10). I was hoping using a multi-thread COM server will do the task; as opposed to having 10 instances of the app attending one dataset each.

You can do that if you have some process that can fire the VFP COM instances (like a Web Server running ASP or other backend, or a multi-threaded app written in C++, Delphi etc. that supports multiple threads of execution). Multithreading in VFP is not really multi-threading - it's apartment model COM instancing which essentially allows multiple COM instances to run simultaneously. It doesn't mean that VFP can run multiple threads of operation...

So, if your solution is all VFP then you will need x number of instances of your app running simultaneously.

>Aside from that, one begs the question: why not use a client/server model instead? We'll get there soon, but till then, we have to patch the hole in the wall.

The article I mentioned is one way to do VFP->VFP client server in asynch manner. It's not always the most efficient way but async operations rarely are even in a real MT environment...

You can do what you want, but it will take resources to do...