>>>Well, you could bring up the app, and have some user interface in teh COM to start the processing, but other than that, I don't see how it would help.
>>
>>Currently, our App runs the LongTask (I keep calling it that), for each dataset (can be more than 10), inside a DO WHILE LOOP. And the LongTask has to finish before I loop back again and run the LongTask if there are still more datasets to be updated.
>>
>>I was thinking if I move the LongTask out of the app and make it a multi-thread COM server; the DO WHILE LOOP will just instantiate the LongTask now in the COM server, and the app will just go on its way.
>
>That's the way of COM. COM is a connected protocol so whatever you do has to finish before it returns to you. THere are ways around this such as using events if the object supports a COM event interface.
>
>Queued components and COM+ events can provide async operation, but in many cases this is not likely what you want because neither of these mechanisms can return a result to you in any way (unless you code the COM component to store a result somewhere).
>
>You can do a lot of things to 'simulate' this process however, by offloading processing to another application or application server. Message Queue (MSMQ) is one way to do this, although I find it limited especially in a mixed environment with lots of non-sequential events. You can also roll your own and that might provide more flexibility - I did just this with an Async manager class described in an article at:
>
>http://www.west-wind.com/articles.asp
>
>That scenario deals with running async over the Web, but it can be applied to any type of application really.
>
>Bottom line to all of this - if you need a result back from these async requests you're going to have to write some code to make this happen.

The real deal of the LongTask:
This is actually a process that will either extract/upload/combination data from a backend database to VFP database of one of our apps & vice versa. The app is tasked to execute data transfers (INSERT/DELETE/UPDATE) based on a record entry in a backend table OR based on a scheduled time.

The surrounding code requires extensive use of SQLExecs() with Macro substitution (!!!not a very good idea, i know!!!) due to the flexibility of defining source and target column, tables, and all the works. The data replication tool of the database was not up to task and VFP dbcs/dbfs are not supported! (hmm, not very surprising...)

I have the option to log results of the task to either in a table in the backend server or in a VFP table. The app is always polling the log table for new entries and is displayed in the app log monitor form.

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.

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.

I'll check out the article in the link. Thanks,