2
votes

I have a Windows service filling cells in an Excel Workbook via OLE Automation.

The save process is not working, the file is never saved. But when done in a GUI app, the save process works.

The service user is an administrator account. I suspect the interaction with the Desktop.

Any idea?

2
Any code for us to see?Nasreddine Galfout
Do you get an exception?Olivier
Do you use an absolute path? Did you check that the service could write in that directory?Olivier
You can write Excel files via ADO/ODBCwhosrdaddy
Nasreddine: nothng easily accessible. Olivier: No exception, the file is not saved. The user have rights to write on the destination folder. whosrdaddy: yes i know, but i need to follow a customer external template.Laurent Saragosti

2 Answers

6
votes

Don't do this. Find another solution. Microsoft does not support or recommend OLE automation of Office software from anywhere but a workstation desktop session. I can't paraphrase any better than what they say directly, so here's the advice (link above goes into more detail) :

All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.

If you need your service to store data, a database is probably a good choice. Any users that require the data in an excel spreadsheet could populate their documents from the database. You could even set up template documents to do this automatically.

0
votes

I had the same problem, run a Delphi software as service, with an administrator user and it gave to me a lot of errors in the read/write process like SaveAs method of Workbook class failed

The solution for read/save was create both folders below:

C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile\

There isn't much sense at all, but it worked.