I remember running into an interesting MSKB article some time ago: http://support2.microsoft.com/kb/257757 .

While it doesn't apply to your situation it does point out that Office is not "server grade" i.e. designed to handle heavy-duty use as an automation server. The product as a whole is not rated for high reliability.

If you're accessing it client-side in a light-duty scenario you're probably OK.

One way to architect an app is to open an instance of an Office COM server and leave it open for the duration of the app. This can be "efficient" in that it doesn't keep opening and closing instances of Office servers.

Because I'm leery of the general reliability of Office I don't do that. Who knows what background cruft may be going on in Excel if you leave it open for any length of time? For each Office COM operation I open a fresh instance for only as long as I need to and close it when I'm finished.

I don't know if it's possible to make asynchronous calls to Office COM servers but I'd advise against that. Even if the calls are synchronous I'd be concerned about "hammering" Excel with intensive calls in rapid succession. If they take any significant length of time to run it might be interesting to look at Task Manager and see if the Excel server is pinning its CPU during the call(s).

For sure, given the gist of the KB article you never want to have a situation where two separate processes are accessing the same Office COM server instance.

>Well, actual re-compile is certainly not an issue, except that in our environment, where building includes updating Source Control and what not, and installing it for our users, it is much more of a hassle than anybody would like.
>
>Beyond that, this happens (has happened) in quite a few different applications, so re-compiling all of them actually IS quite a bit of work.
>
>So your guess (and everybody else's, it seems) is that the problem is with datatoclip somehow -- that occasionally, operating on exactly the same data, it fails to produce anything?
>
>
>
>>>Well, actually, I can't do that. I restore the clipboard after using it, so there's no evidence left.
>>>
>>>As this problem occurs in any of a number of applications, I would have to recompile all of them.
>>>
>>>Furthermore, the actual code is:
>>>
>>>

Select(lcExportAlias)
>>>Goto Top
>>>DataToClip(lcExportAlias)

>>
>>Well your DataToClip() should be doing that... but for debug mode, you could check the used row count in excel before and after pasting - if it didn't increase, then strtofile(_cliptext, "some name derived from datetime()") and see what you got in there.
>>
>>Recompile doesn't hurt much nowadays... I remember when that was an excuse to have a break, now it's not worth trying to begin anything else. The app I'm most frequently busy with has an exe of about 20 megs, compiles in 5-6 seconds and my machine is about four years old.