Create Excel Object produce error: Automation object error

...
Print "Before creating Excel Object"
Set xlApp = CreateObject("Excel.Application")
Print "Create Object OK"
xlApp.Workbooks.Add
Print "Add Workbooks OK"
xlApp.ReferenceStyle = 2
Print "Add Reference Style OK"
xlApp.DisplayAlerts = False
Print "Add Display Alert OK"
Set xlSheet = xlApp.Workbooks(1).Worksheets(1)
Print "Add Worksheet OK"

Select allOpen in new window

The code throws an error when it hits xlApp.Workbooks.Add

As Sjef suggested, I guess that Excel is not installed on the server.

Since most admins aren't very keen on having MS Office (or other non-Domino stuff) installed on "their" Domino server, I often choose to create the xls file in html format.

Just save your current Excel file as html and look at its sourcecode. You can produce the same output yourself by just using "open", "print #" and "close #". You may even leaveparts of the original code (xml / styles) out.

It'll work from a scheduled agent as well as actions. It'll even work in web apps and you can still freeze panes, predefine auto filter etc.

1. Windows Server 2008 R2
2. It was not, now it is. Sorry my mistake.
3. Yes
4. You mean who sign the agent? Currently it is me, but will change to server's id

Now, after Installed Excel, I did not get Automation Object error but

... error message: Microsoft Office Excel: SaveAs method of Workbook class failed

Below is the code that I use for saving the Excel file

...
xlApp.ActiveWorkbook.SaveAs file_Path, 56
xlApp.Quit
...

Select allOpen in new window

Find something that I will try in a minute:
http://per.lausten.dk/blog/2011/04/excel-automation-on-windows-server-2008-x64.html

4. No, that's not what I meant. When the server runs as a service, without a user account specified, it runs under a System account that has little or no privileges.

Most likely cause: the server has no access to file_Path.

Suggestion: use c:\Temp as file_path, and include a simple test to find out if the server is allowed to write a file in file_path.

I use the path below to save the Excel file:

file_Path = "C:\Windows\SysWOW64\config\systemprofile\Desktop\" & "WO_Pending_Approval_" & Year(Now()) & "_" & Month(Now()) & _
	"_" & Day(Now()) & "_Terr" & terr & ".xls"

Select allOpen in new window

and SYSTEM user account has a Full Control over the folder, but still the same error.

I will try your Temp folder suggestion, sjef.

@CRAK
The users specified that they want it in Excel file. If I understand your suggestion, then I just send the HTML file? That is not going to work on my case.

My standard "approach" is: stuff Excel, just create a .csv file ;-)

I wish you are my manager ;-) Originally it was created in CSV, but I was told that it was not pretty

still no light ... all the solutions that I can see points out on creating that Desktop folder. But still does not work for me. I even added NETWORK SERVICE to the Security tab... rather frustrated

http://stackoverflow.com/questions/863864/excel-2007-automation-on-top-of-a-windows-server-2008-x64

No luck with C:\Temp either?

What is the intended result? What if you send the users a URL to the Domino server, and when they click it they get an Excel screen in the browser with the data they need? If they want to save the file, they can do that. Could that be the idea?

No luck with C:\Temp either. Does it matter that the Excel version that I put on the server is 2003 version?

The intended result is an Excel file that is sent to users email.

I am not quite sure about the idea that you mention sjef. How do I start on doing that?

ok seriously yes that is the problem. I am using MS Excel 2003. The format is 43 instead of 56

You can develop a web agent that sends data to the user's browser in "excel" format: html code that Excel interprets as a spreadsheet.

Example:
- http://www.botstation.com/code/view2excelweb.php
- http://www.codestore.net/store.nsf/unid/EPSD-559R3S/ (rather old, but explains it well)

The essential line is always this one:
      Print |Content-Type:application/vnd.ms-excel|

If the next line:
      Print |Content-Disposition: Attachment; filename="|+filename+|"|
is left out, the browser embeds an Excel-object all by itself to display the data you send. You can apply colours using CSS.

The users specified that they want it in Excel file. If I understand your suggestion, then I just send the HTML file?

What the users mean is that they want the file opened/presented in Excel. They're not interested in how things work "under the hood"!
You can still name the html file ".xls", or add a header to the file so Windows will know what to do with it.
My users asked for Excel just as well. None ever complained and I never had to negotiate the installation of MS Office on a Domino server.

Anyway, you've managed to have Excel installed. That was the biggest reason to find an alternative. There's no reason now have this discussion! ;-)

Now it is not working again and I did not change a thing since my last change.

:scratching my head:

Ok finally got it to work using this combination:

http://stackoverflow.com/questions/863864/excel-2007-automation-on-top-of-a-windows-server-2008-x64

xlApp.ActiveWorkbook.SaveAs file_Path, 43

Select allOpen in new window

Thanks for helping me think this through

I've requested that this question be closed as follows:

Accepted answer: 0 points for coronoahcoro's comment #38194248

for the following reason:

Find solution from the external link

No sir, sorry, but you're not playing fair, and I can't accept that you close this question like that. You didn't know why you got the Automation object error, and that's what we explained you all about. That problem was solved. The discussion that followed should have been in one or more separate questions.

The original question is about an automation error.
In http:#a38194206 the asker confirms that Sjef's suggestion helped in solving that issue.

Appearently, the asker got then stuck on secundary issues and may have managed to solve those without further help, but we're all familiar with EE's set of rules aren't we?

I recommend accepting http:#a38192236.