March 19, 2010 at 7:44 am
I wrote a SSIS script task where I use VB code to read data from a database using ODBC and then dynamically create an excel spreadsheet using the Microsoft.Office.Interop.Excel object. The code then saves the spreadsheet to a directory folder on the sql server. The server OS is 32 bit Windows Server 2008 Standard, and SQL Database is SQL 2005.
When I execute the package in the SQL Server Business Development Studio on the server, it works perfectly and the package writes the spreadsheet to the folder on the server without any problem.
I then save the package on the server using "Server Storage" and I set up a scheduled job to run the package. Every time the SQL Agent runs this job , I get this error
Message
Executed as user: XECC\Administrator. Microsoft (R) SQL Server Execute Package Utility Version 9.00.4035.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 8:49:42 AM Error: 2010-03-19 08:49:46.69 Code: 0x00000002 Source: create_spreadsheet Description: The script threw an exception: Exception from HRESULT: 0x800A03EC End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 8:49:42 AM Finished: 8:49:46 AM Elapsed: 3.884 seconds. The package execution failed. The step failed.
I have created many other packages before using script tasks and I have used the sql agent to execute them, and I never have had a problem before. I should note that none of my previous packages used the Microsoft.Office.Interop.Excel object to create an Excel spreadsheet, so maybe this is some how causing the problem.
I created the job step for executing the SSIS package using SQL Server Authentication since I saved the package to the server using "Server Storage" with the same login account.
I did a test and I commented out the statement in the VB script that actually saves the workbook to the folder on the server and when I executed the job in the SQL Agent with this statement commented out, the job worked fine without an error. When I remove the comment and try to write the spreadsheet to the folder, I get the that same error .
Here is my Vb code
sql = "select * from logs order by [0]"
cmd = New OdbcCommand(sql, cn)
rs = cmd.ExecuteReader
Dim app As New Microsoft.Office.Interop.Excel.Application
Dim WB As Microsoft.Office.Interop.Excel.Workbook
app.Visible = False
app.UserControl = False
app.DisplayAlerts = False
WB = app.Workbooks.Add
WB.Application.Cells.Select()
WB.Application.Selection.NumberFormat = "0"
Do While rs.Read = True
k = CType(rs("0"), Integer)
For i = 0 To 170
If IsDBNull(rs.Item(i)) = True Then GoTo finish
j = i + 1
WB.Application.Cells._Default(k, j) = rs.Item(i)
Next
finish:
Loop
rs.Close()
WB.Application.Cells.EntireColumn.AutoFit()
WB.Application.Range("A1").Select()
WB.Sheets(1).Name = "logs"
When I comment this statement out, the SQL Agent job works fine.
==================================================
'WB.SaveAs("D:/excel_folder/logs.xls")
================================================
WB.Close()
WB = Nothing
app.Quit()
app = Nothing
System.GC.Collect(0)
System.GC.WaitForPendingFinalizers()
cn.Close()
cn.Dispose()
Dts.TaskResult = Dts.Results.Success
I am wondering if because Excel is involved now is there something in security that is causing the job to fail?
I am wondering if because Excel is involved now in this package is there something in security that is causing the job to fail?
March 19, 2010 at 9:38 am
How you are calling the SSIS package from the job, I mean through dtexec? There are issues with support to 32 bot and 64 bit excel... Please read more on this....
VG
March 19, 2010 at 11:38 am
Everything on the server is 32 bit. There is no 64 bit software.
March 19, 2010 at 11:52 am
If you physically log in to the server as user XECC\Administrator and then execute the package through BIDS, does it execute OK?
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 19, 2010 at 12:38 pm
I physically signed on to the server as Admin and executed the package in BDIS and it worked fine and wrote the spreadsheet to the file as it is suppose to do..
I then opened the SQL Server Management Studio and connected to Integration Services and executed the package from there, and again it worked fine .
I then created a new SQL Agent job being signed on as Admin and when I ran the job which executed the package, it failed with the same error message as before.
April 12, 2010 at 3:51 pm
What account does the SQL Agent run under and does that account have the appropriate share permissions to write files?
April 26, 2010 at 6:04 am
if you use microsoft.interop.excel then only admin and the system user had the permission to generate the excel.so create a proxy account and call the job through that account.
May 11, 2010 at 8:34 am
Hiya, I had this problem too.
The way I solved it, was by creating a folder called "Desktop" in "C:\Windows\System32\config\systemprofile\" and I was able to run it without any problems.
I hope that helps 🙂
November 18, 2010 at 5:05 pm
I was having this problem too.
I fixed it by remote desktop'ing into the server that the SQL Server Agent was running on. Instead of logging in with my own user account, I logged in with the same account the agent service is running under. Then, I opened up Excel.
It ran through all the first time user popups, like prompting me to verify my name and initials, if i wanted to activate excel, if i wanted to get automatic updates, etc.
Once I did that, the job started working.
March 12, 2012 at 12:15 pm
Hi Charles,
Did you managed to get it working. I have the similar issue.
Thanks
Sree
July 31, 2014 at 4:17 pm
Thanks for the suggestion... this worked for me 😀
We were trying to figure out access issue but nothing worked before I created the folder in the mentioned location.
Suresh
July 31, 2014 at 4:18 pm
ajagadambe (5/11/2010)
Hiya, I had this problem too.The way I solved it, was by creating a folder called "Desktop" in "C:\Windows\System32\config\systemprofile\" and I was able to run it without any problems.
I hope that helps 🙂
Thanks for the suggestion... this worked for me [BigGrin]
We were trying to figure out access issue but nothing worked before I created the folder in the mentioned location.
Cheers!
Suresh
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply