>>>>Saw between my getting newest and writing my stuff Lutz already pointed to "keep alive" via repeated msg.
>>>>Certainly works, and reaction times when using BindEvent or repeated checks are not bad.
>>>>If running on the same machine my default would still be COM exe and for running on other machines msg records/memos in dbf used by both or all to avoid DCOM. //Edit: if processes on same and other, default to table to keep it KISS
>>>>
>>>>>>Whenever your main process runs into bad errors like C0000... chances are your kill command will not be sent.
>>>>>That is true, although it would not cause any real issues if the process would have stayed alive by mistake, and those errors are relatively rare.
>>>>
>>>>Do it correct from start on - even if using files to flag "keep alive", so no technical cruft is in place if you need to spawn more often for new task...
>>>>
>>>>>>So the basic message has to be "main process still alive" - easy to handle with a .dbf used by both and main process holding a lock on a certain record. Main process dies, lock evaporates, system process realizes that on next check and terminates itself..
>>>>>
>>>>>File lock is a good way, otherwise I would have checked in the process if the result has been picked up since the last call, so that would not have been a big problem in this case.
>>>>
>>>>Benefit of msg dbf is that scaling to other tasks is simple: each task gets 3 records, 1 to send, 1 to receive, 1 for own alive plus master record for main process alive. Record locks enough for keep alive, so everything is compact, tidy and fast.
>>>>
>>>>>>Although for me it is not clear why you cannot compile the "system" part as COM exe and run out of process with a COM communication directly betwenn both processes, as your description does not point to load balancing or work distribution, only as wish to use another Thread and Core.
>>>>>
>>>>>Indeed I could create a com exe, but would it not just instantiate the class and run in the same thread? Or how else should I call the method?
>>>>
>>>>COM dll = new in process thread (STA model), COM exe = Out-of-Process
>>>>Marshalling across process boundries 5 to 10 ten times slower, but still no problem according to Rick, who prefers Exe for less danger even in his server backends which can get high usage. So no worry on that front if it works for Rick ...
>>>>
>>>>regards
>>>>thomas
>>>
>>>I created a com exe, but still don't get the idea how the process would run without the calling application waiting for the result:
>>>loProcess = Createobject("Test.Test")
>>>loProcess.Execute()
>>>
>>>Then it waits until it's finished, but that should not be the case. Do I need to do something else?
>>
>>It really depends on what the process should do. Personally I used this solution for reporting, sending emails and a few other tasks. The users were really happy to start a report, and be able to continue with their work straight away. As soon as the report finished, it arrived by email.
>>
>>If you can give more info, I can see if I can give you some more ideas.
>
>Basically it connects to SQL Server, runs a query, if anything is found it formats the data and creates a table in the temp folder.

So the time consuming part is the query itself?