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 :

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.
JulieSenior Analyst/ProgrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vitor MontalvãoMSSQL Senior EngineerCommented:
The agent is running under your account but what about the job? It's the owner of the job that matters not the SQL Server Agent.
You can also run a SQL Profiler to verify if the job is at least doing something on the database.
JulieSenior Analyst/ProgrammerAuthor Commented:
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 :

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

JulieSenior Analyst/ProgrammerAuthor Commented:
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 :

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 ....
Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.

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.


JulieSenior Analyst/ProgrammerAuthor Commented:
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 ...
Yes. It seems, from what you said,  that it was the creation part that was failing. Hopefully that was the right diagnosis!

JulieSenior Analyst/ProgrammerAuthor Commented:
Hi Mike

I've managed to perform some further testing, and I've found that the file gets copied successfully, it just can't open it.  The error message is :
Microsoft Excel cannot access the file '<folder>\<name>.xlsx'. There are several possible reasons:

The file name or path does not exist.
The file is being used by another program.
The workbook you are trying to save has the same name as a currently open workbook.
Unfortunately, to all intents and purposes, this is the same message as when I was creating a new workbook based on the template.

Still an automation issue then I assume?
Probably. Can you not write into an existing workbook with the Excel connector in SSIS?
JulieSenior Analyst/ProgrammerAuthor Commented:
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

JulieSenior Analyst/ProgrammerAuthor Commented:
Just as a postscript, I can schedule the package to run using DTExec and Windows Task Scheduler ... another ball to keep in the air, but as long as one scheduler or another can generate the workbooks, I'm happy.  It's not been all for nothing!

Thanks again to all


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JulieSenior Analyst/ProgrammerAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.