Unexpected results running SSIS package, using execute process task, in SQL Server Agent (2008R2)
I've been banging my head against a brick wall for what seems like forever. This is what I have done :
This package works successfully when I run from BIDS. It works successfully when I publish the package into SSIS. It works successfully when I run from a command prompt using "DTExec.exe". What it doesn't do, is run as a scheduled job using SQL Server Agent. Well, strictly speaking, it does run, I get no errors, but the expected Excel files do not get created. Task manager shows me that Excel instances are being created/destroyed on the fly.
The agent is running under my logged on account, so there should be no issue there (hopefully). It is running on the same machine from which I designed all the elements, so there is no issue with a different setup. It doesn't use UNC path, the application is run directly from the c:\ drive. It is set to run using 32-bit runtime, hopefully that eliminates an issue we've come across with Office on the production server. I've tried turning on package logging, but it tells me little else other than when each iteration starts and finishes. I've added scripts tasks to write what is passed to the exe to a log file, all commands look OK.
I'm at a loss. I'm obviously missing something very basic, but I'm b***** sure I can't see it. Any guidance would be appreciated.
Thanks in advance.
Written a VB.Net console application (lets call it myvb.exe) which accepts a number of parameters and creates an Excel 2010 workbook
Created an SSIS package which iterates a number of records in SQL Server and executes myvb.exe
This package works successfully when I run from BIDS. It works successfully when I publish the package into SSIS. It works successfully when I run from a command prompt using "DTExec.exe". What it doesn't do, is run as a scheduled job using SQL Server Agent. Well, strictly speaking, it does run, I get no errors, but the expected Excel files do not get created. Task manager shows me that Excel instances are being created/destroyed on the fly.
The agent is running under my logged on account, so there should be no issue there (hopefully). It is running on the same machine from which I designed all the elements, so there is no issue with a different setup. It doesn't use UNC path, the application is run directly from the c:\ drive. It is set to run using 32-bit runtime, hopefully that eliminates an issue we've come across with Office on the production server. I've tried turning on package logging, but it tells me little else other than when each iteration starts and finishes. I've added scripts tasks to write what is passed to the exe to a log file, all commands look OK.
I'm at a loss. I'm obviously missing something very basic, but I'm b***** sure I can't see it. Any guidance would be appreciated.
Thanks in advance.
ASKER
Hi Vitor, thanks for responding.
I've run a couple of queries on sysjobs and sysssispackages and they appear to be owned by my logged on account.
Few things maybe I should have mentioned :
Thanks again
Julie
I've run a couple of queries on sysjobs and sysssispackages and they appear to be owned by my logged on account.
Few things maybe I should have mentioned :
I'm running SQL Server 2008 Developer Edition (R2) - don't know if there are limitations to the agent
The exe is compiled using Visual Studio 2010 as 32-bit and references Office 2010 64-bit assemblies
The project is configured "Run64BitRuntime = False"
The package is configured "Use 32 bit runtime"
Thanks again
Julie
ASKER
Ok, done some further testing and introduced debugging in the vb.net application, and discovered that when running the exe through the SQL job, it can recognize the folder and access it, locate the file required, but can not create a new workbook based on it. I'm assuming it is an Office automation issue. I found the following :
Do I assume I've hit the unstable behaviour mentioned above? I have references to the Office assemblies in the visual studio project and use early binding.
Quick question, would the same be true if I use late binding and object references? Is that still considered Office Automation? I'd rather avoid a lot re-programming if the principal is flawed.
Unless I've totally misunderstood ....
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.
Do I assume I've hit the unstable behaviour mentioned above? I have references to the Office assemblies in the visual studio project and use early binding.
Quick question, would the same be true if I use late binding and object references? Is that still considered Office Automation? I'd rather avoid a lot re-programming if the principal is flawed.
Unless I've totally misunderstood ....
Are all your workbooks the same before you write data into them? At least, are your workbooks always one of a number of pre-known formats? If so, then create blank copies of each type of workbook ahead of time and keep them in a templates directory.
At run time don't create a new workbook - instead, copy the appropriate workbook for the task you're about to carry out to the working directory (leaving the original in the templates directory).
This way you never create a new workbook in the job.
hth
Mike
At run time don't create a new workbook - instead, copy the appropriate workbook for the task you're about to carry out to the working directory (leaving the original in the templates directory).
This way you never create a new workbook in the job.
hth
Mike
ASKER
Thanks Mike
The workbook template is the same. I was creating a new workbook based on the template, changing the query definition within each sheet on the fly, and saving as a new workbook.
OK, I understand what your saying, copy the master to a new file, change those query definitions, and save. You think that gets round the Office Automation limitation because we're performing file manipulation instead? It will require some re-programming, and time, but I'll give a try.
Where there's a will there's a way ...
The workbook template is the same. I was creating a new workbook based on the template, changing the query definition within each sheet on the fly, and saving as a new workbook.
OK, I understand what your saying, copy the master to a new file, change those query definitions, and save. You think that gets round the Office Automation limitation because we're performing file manipulation instead? It will require some re-programming, and time, but I'll give a try.
Where there's a will there's a way ...
Yes. It seems, from what you said, that it was the creation part that was failing. Hopefully that was the right diagnosis!
Mike
Mike
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yeah, that's how I arrived at this party, I just wasn't happy with the formatting and I couldn't get it to work with *.xlsx.
Plan D then ...
Thanks to all for your suggestions
Julie
Plan D then ...
Thanks to all for your suggestions
Julie
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Although the suggested tip did not resolve the problem, it confirmed I could not achieve what I wanted using the method I had been employing. This helped lead me to finding an alternative way getting the desired results.
You can also run a SQL Profiler to verify if the job is at least doing something on the database.