>Hi all,
>
>A client of mine is having me develop a Word automation app to create booklets in Word by pushing across tables etc using Word automation. The overall process of firing up Word and creating the tables and all that is going swimmingly and creating the docs on their PC's if fine (albeit somewhat slow).
>
>Once this app gets into full production, they would rather have this app sit on a server and have a VFP app scan a table looking for data to process into a booklet. That is, it will check a table and if a new record is added, it would fire up this Word automation app, fire up Word, create the booklet and then drop it back in the user's directory (on the server).
>
>I have done something similar with long reports so that user's submit a request for a report and then check back later in their directory - but that all within the VFP report writer. In this case, I am a bit concerned that with Word being somewhat "flakey", creating 100 - 200 instances of Word a day and then destroying them, or just creating that many docs in a Word instance is going to cause Word to fail (memory leak etc).
>
>Anyone done this - offloading Word automation to another server and then crank through lots of docs? Also, your opinion of what might be best:
>
>1) use the VFP app to create a Word instance, process the document and then close (quit) the Word instance each time (to clear memory used by Word - but slower to load and perhaps loading/unloading Word 100 times a day will also have probs)
>
>2) use VFP to create a Word instance but then "recycle" the instance each time so that the docs are closed each run but Word stays open.
>
>Opinions?

Haven't done that with Word in a busy environment, but I did have Word running long batches, creating maybe a few hundred documents (converting from rtf to doc and/or vice versa, extracting sets of paragraphs from one long document and saving them as separate ones), and didn't notice much of a problem. Did more with Excel (as a reporting tool), where it would churn about 20M worth of xls files in a couple of minutes (when run from the server via Citrix, or 20 minutes on a crummy overloaded workstation).

The pitfalls are that in case of any serious error, which would cause your app to quit, a hidden copy of Word or Excel may be stranded in memory with nobody to tell it to unload, and that would create a problem. Also (at least with Excel 2003, maybe Word too) if your user opens Excel while your app is running one, the same instance is opened and your user actually sees what your app is doing. Then if the user closes Excel completely, your app may need to handle the "I lost my COM object" situation. Another potential issue with closing and reopening a COM server is that there may be some latency - the COM server may disconnect and your app would go on, but it may still be cleaning up when you try to launch it anew. I know a few apps (Firefox, for instance) that you can't just reload immediately, you need to wait a few seconds.

Which is why I'd rather run this as a job queue app on the server - would be faster as well, specially if your users are running their own copies of Word - I'm not sure how that behaves.