*snip*
>Why do you call it a "poor mans alternative"?
>
>That's a nice idea! Although I would need to create an all new EXE with all the necessary functions in it and configure all the computers I might want to run it on accordingly shoudn't I? Either way (using COM or this method), I need to configure a lot of stuff so they both seem valid.
>
>One question comes to mind though, can I build a DCOM server using FoxPro (or should I build it using C++ and all it's wizards)? Plus, is it easy to build clients in FoxPro that'll communicate with DCOM objects written in another language?

That's the power of COM. It gives you a level playing field to interact between components. I've developed COM servers in VB and used them with no problems in VFP. Others here haved used VC++ to develop COM servers for things they needed to do.

FWIW, from your original post, I don't know if the AT solution works for you (it may). However, AT is typically used to schedule a lengthy process that occurs when resource usage is low or non-existent (e.g. pack databases at 0200 when no one is on the system). Instead of writing an application that periodically checks the time and fires the process up, NT automatically fires up the application at the scheduled time. Your application is not taking any resources (e.g. memory, network connection, etc.) because it isn't running until it needs to.

If you were to use this solution, then depending on the time it takes to run your comparisons, you could fire up your application at 0100 and it would probably be done when people came in to the office in the morning. As I said, this may or may not be what you want.

A "true" poor man's DCOM solution, is to use table entries as your messaging tool. Create your separate applications and run them on the many machines. They would each periodically check a central table for tasks to perform (with parameters if necessary). Once the machine found a task for it to do, it would launch that process and when complete change the status flag for that task. The master system would peridically check the status flag of all the jobs it "spawned" and when all were complete it could gather the results from a pre-defined location (e.g. text file, another table).

HTH.