Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1354
  • Last Modified:

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.
0
AHJ2008
Asked:
AHJ2008
  • 7
  • 3
3 Solutions
 
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.
0
 
AHJ2008Author 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

Julie
0
 
AHJ2008Author 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 ....
0
Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

 
DcpKingCommented:
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
0
 
AHJ2008Author 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 ...
0
 
DcpKingCommented:
Yes. It seems, from what you said,  that it was the creation part that was failing. Hopefully that was the right diagnosis!

Mike
0
 
AHJ2008Author 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?
0
 
DcpKingCommented:
Probably. Can you not write into an existing workbook with the Excel connector in SSIS?
0
 
AHJ2008Author 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

Julie
0
 
AHJ2008Author 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

Julie
0
 
AHJ2008Author 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.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 7
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now