>Oh @##$!!!#@#. I hate hitting brick walls.. I was afraid of that. I wonder what calling the exe server will do to performance. I originaly had the whole progam as an exe server but it had all kinds of trouble when we had multiple people on at same time. It was fine with only one person. Well i guess as long as they dont run the report at the same time.
>

If returning the report result to the end user directly isn't an issue (which appears to be the case here) why not simply run some sort of simple job server scheme without getting COM involved at all? Simply queue up reports through a simple mechanism (a table containing scheduled work items perhaps) and have one or more machines (or sessions on a single machine) simply pole the queue for pending work when they aren't doing something, run the requested task, and post notification back to the queue (in this case, update the table with a completion status and perhaps the name of a resulting file.) No mess, no COM layer needed, and instantly scales by simply having new job servers go on line and poll the pending work table.

Obviously it only works if the request can be serviced asynchronously or where you can poll for results; I'd guess that in most cases this wouldn't be a problem, and you could make the submitter spin on job completion if it required synchronization by polling the job record.

You could also use MSMQ, but again, for simple scenarios, it's not worth the added work and system requirements.