|
I have a SSIS script task that formats an Excel spreadsheet - this was converted from DTS/ActiveX where I had no problems. I've checked the GAC to make sure that the Interop.Excel is there and it is. I can run this step in BIDS without a problem, but when I run this as a scheduled job it fails - or more accurately, it runs but doesn't format the spreadsheet. Since I've got 100s of similar tasks to convert, I can't continue to manually execute the process every time it needs to run. What am I missing? Here is the main part of the script:
(comments are locked)
|
|
I have used the excel interop assemblies fairly extensively in the past, but it has been a while so I'm a little rusty. Am i right in saying that it is opening an existing excel document? If so, where is it getting the file path from? i.e. D:filesfileToFormat.xls. I can see it's creating the excel object, but the file name is just a filename and no path so how does it know where to save it? There also might be a security issues, the sql agent doesnt normally have access to the local drives, so I suggest creating a identity (not your own credentials, a service account) and SSIS proxy account using that identity to run the package, and make sure that account has access to the file location.
(comments are locked)
|
|
Thanks, Daniel. I'd removed the path from the sample but in script it is fully-qualified. I've checked the permissions and they seem to be fine. Let me qualify that - I have plenty of other jobs which are creating spreadsheets in the same location without a problem. But you may be onto something since I was able to expand the task error handling and now get "Microsoft Office Excel cannot open or save any more documents because there is not enough available memory or disk space. " although there are 17G available and nothing in any of the temp folders. Since I got this error after rebooting, I don't think memory (4G) is an issue. I'm going to try logging in as the sql agent account - maybe that'll give me a better idea. ok, it seems that the script (or another script) is not closing the excel object down correctly. try logging into the server and see if there are lots of excel instances running in the processes tab. make sure you show process from other users. if there are then they are not closing down correctly.
Jan 15 '12 at 06:53 PM
Daniel Ross
(comments are locked)
|
|
Thanks, Daniel. I was finally able to get it to run by setting the properties of Microsoft Excel Application, under Identity, to The Interactive User from The Launching User. This setting is different from what it was on the old win2003 production server. If I understand what it's doing, it retains the admin account information and uses that account to launch excel.
(comments are locked)
|


By chance is your workstation where you are developing and testing this 32 bit and the server you are trying to run it on 64 bit?
Sorry, the development station and the server are both 64 bit - Windows 2008 R2 sp1.