>There are a couple of ways you could go, both use COM+. You can use Queued Components, COM+ Events, or a combination of the two. Again, there's an article on my web site.
I skimmed/read your article
http://www.craigberntson.com/articles/complus.pdfNice articles BTW, pretty easy to read and understand. I hadn't considered DCOM.
I've think I've narrowed down my choices to DCOM or Named Pipes. DCOM seems to have significant overhead and seems like overkill for what I need, named pipes seems like it might be a bit simpler overall. But let me describe my scenario.
I have 2 types of apps in this scenario.
* A C# WPF App which posts the specs needed for the VFP apps to an MSSQL server and then initiates the process and monitors it's progress.
* Multiple VFP Apps which get their instructions from the MSSQL server and then do the actual work (Note: all VFP tables are single user.)
The C# app can terminate at anytime and the VFP App would continue to run in the background till it completes.
The C# app will also be running on multiple computers. Possibly even monitoring the same VFP job.
The VFP apps have no user interface.
Some of the VFP apps are actually managed by a service that is running on a Win2K server.
The server gets it jobs from a cue and processes them sequentially.
Because the server app creates very heavy loads on the system it is single threaded.
The C# app can view the data and handles manual corrections to bad records.
The important data about the process is all persisted using the MSSQL server. So I don't have to worry about any lost events. The purpose of the interprocess communication here is just to make things a bit snappier for the C# monitoring and control programs. Rather than polling for updates it can just listen for the events as they occur. A lost event would not be a real big deal.
So... in this scenario, what would be the advantage of DCOM over named pipes?
