What are the drawbacks of using server-side Automation of Microsoft Office?

[Mr.ken]

Hi friends,
I have recently started with the topic of an automation that resides in Microsoft Office. I am not having much idea about the server-side automation. And I have to complete my assignment, by explaining the drawbacks of it. So I thought that you will help me (as usual). Please tell me what are the drawbacks of using server-side Automation of Microsoft Office? Since, I don't know much about an automation, also explain me about the same.!!

[Zenon]

f you create a solution that runs in a server-side, you should wherever possible try to use components that have been designed to be run unattended reliably or find alternatives that allow at least part of the code run client side. If you choose to use an Office application from a server-side solution, you may find it lacks many capabilities to run correctly and you risk compromising the overall stability of your solution.

[Bigga Lexx]

Developers who try to use Office in a server-side solution must take into account five major elements for which the environment results in unexpected behavior of Office. If you want to run your code without problem, these situations must be addressed and their effects minimized as much as possible. When you create your application, consider the issues with great care because there is no solution can all be treated. Each type of design requires you to rank them differently.

[super soaker]

The performance of Office applications requires the identity of a user even if they are started through automation. They attempt to initialize toolbars, menus, options, printers and certain supplements based on settings in the registry hive for the user who launches the application. Many services run under accounts that are not associated with any user profile (such as system account or IWAM_ [servername]) and therefore Office may not be properly initialized at startup and return an error on the CreateObject or CoCreateInstance.

[DANIEL 602]

Office applications need to be performed on an interactive desktop and must sometimes be made visible for certain Automation functions to work properly. In case of unexpected error or if unspecified parameter is needed for a function, Office normally invites the user to select a mode of action using a modal dialog box. On a non-interactive desktop, the modal dialogs can not be closed, causing the thread to hang indefinitely. Although certain coding practices can help reduce the probability of occurrence of this problem, they can not eliminate it entirely. This fact alone explains why the performance of Office applications from an environmental server side is risky and unsupported.

[NIcaBoy]

Server-side components must be multi-threaded COM components highly reentrant, capable of providing a minimum overhead and high throughput for multiple clients. Under almost all reports, the Office applications have the opposite characteristics. They are ATS Automation servers, not reentrant, designed to provide different features, but resource-intensive to a single customer. As a server solution, they offer a low level of scalability and are also subject to fixed constraints, particularly in terms of memory, which can not be changed through configuration. Moreover, they use global resources (such as memory mapped files, additions or global models and shared Automation servers) may limit the number of instances that can run simultaneously and cause race conditions if they are configured in a multi-client environment. Developers who plan to run multiple instances of an Office application must provide access through a group or a serialization to avoid potential deadlocks and data corruption.