Hi!

If you plan to do this as completely independed process, then keep in mind that COM object will be destroyed as soon as you exit the client application, or just release all references to that COM object. This means that you require to organize this by another way. For example, some table holds a parameters for running processes. Some service aapplication looks into that table once/5 minutes and run scheduled processes when found.

Another example is running a separate EXE from the COM object that will do the job, while the COM object itself is free for use and releasing without interrupting the long process.

>>It is depended on the way you call this COM object. For example, imagine situation when you call the COM object to request a lengthy operation for it. After that in some other place in the program you try to call the COM object again to get another data and cannot, because COM object is busy working on previous task. As far as client application aware about such thing, no problem.
>>
>>There are no otehr issues as far as I know.
>
>
>
>No no, this is ment to be as an independend instance for Background-
>jobs like Data-Exchange etc. on a scheduled basis
>
>The jobs will take max. a Minute or so. And in order to be sure I
>always do add a flag .l_Busy that is .T. as long as a task runs.