I've been tasked with deploying a handful of SSIS packages on Microsoft SQL Server 2012 Enterprise 64-bit (11.0.6020.0) running on Windows Server 2012 R2.
The packages run perfectly when run from SQL Management Studio by right-clicking the package and clicking execute with the proper parameters.
However, when I schedule them to run under the SQL Server Agent, some of them fail. I have not been able to identify any pattern that distinguishes the failing packages from the working packages.
All of the packages are run using a, probably unconventional, approach which involves creating the job step in the job as a Operating system (CmdExec) step rather than a SQL Server Integration Services Package step. This is because the packages depend on access to a particular SMB share and must have credentials provided first to access this share. The CmdExec step calls a wrapper batch file and passes the package name and the environment reference for dtexec to run the package.
Here's the file bat file:
set ETL_PACKAGE=%1
set ETL_ENV_REF=%2
net use \\remote-share.some-domain.local\dropfolder\in /user:ssisagent mypassword
dtexec /Envreference %ETL_ENV_REF% /ISSERVER \SSISDB\%ETL_PACKAGE%
if "%errorlevel%"=="1" (
exit /b %errorlevel%
)
When the agent runs these jobs by rightclicking the job and selecting "Start Job at Step..." the job is started succesfully, but when you pull an execution report it fails with this error:
Message Source Name: Transact-SQL stored procedure
Operation is not valid due to the current state of the object.;
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ISServerExecutionEvents.LoadPackage(PackageItem item)
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.StartPackage()
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.PerformOperation()
I would appreciate ANY idea about what could possibly cause this error or how I can troubleshoot it to narrow down the causes.
I have tried setting up a proxy account using my own admininstrator credentials to rule out possible permission issues, but it doesn't change a thing. I have checked permissions on the SSIS environment used, but that doesn't change anything.
The packages in question interact with DB2, MS SQL and various fileshares with CSV/XML files.
Related
I work with Microsoft Access 2016 with a SQL Server 2008 R2 backend. I have used SQL Server Management Studio to create some SSIS package for quick copying of data (right-click DB -> Tasks -> Import/Export).
I was able to create a button in Access to kick off the SSIS package successfully using VBA. I use the Shell function to run the following command:
"C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\DTExec.exe" /F "\\MyPath\MySSISPackage.dtsx". This works on my machine because I'm running my particular instance of DTExec.exe to execute the SSIS package.
I need to set up users' Win10 64-bit computers now so that this process will work for them as well. I don't know if DTExec was installed when I installed SSMS or my local SQL Server Express Edition DB, but the user doesn't need either of these programs. What is the bare minimum I need to install on the users' computers for it to work for them also?
I've done a lot of googling but either the scenario didn't quite fit mine, or I just wasn't understanding what they were talking about. The users will have Microsoft Access only as a start.
Links to download locations would be extra appreciated!
Thanks!
For running SSIS packages in a production environment you must install and license SQL Server. A user who only has Microsoft Access installed cannot run SSIS packages.
You can install and run SSIS packages on your SQL Server (Standard Edition or higher), but not on your clients' PCs.
Once you have credentials all sorted out with DBA team. At min you will need read (select permission) on desired database(s) . Build your ssis in VS2017 locally and test. It will run great I'm sure. And when your ready to deploy you can use steps below.
Steps below outline package deployment mode.
I have an SSIS Package deployed in the Integration Service Catalogs of Sql Server 2014. When I run the package from the catalogs all works perfectly, the sql server session works with an authentication windows. I have created a job in Agent Sql Server to run this package, I am the owner of the job and I have admin rights on Sql Server, the step that runs the package is run as a service account SQL Server Agent. But when running the job it crashes with the following error:
Load FTP file Qc: Error: The directory is not specified in the User Connection Manager::DownloadDirectoryQc.
But it is beautiful and well otherwise it would not work catalog. Would anyone have a reason for what is causing this problem?
You may need to create a configuration file that the job can use to find connection manager information, such as the download directory path. This information may be available in your environment when you run from the catalog in SSMS, but isn't available to the job when it runs. Configuration files help with this problem. (Also, see discussion here).
Simple question: how does the execution of a ssis package differ when using the SQL Server 2012 Integration Package Utility versus when using the 2012 SQL Server Agent to execute a package? (holding all else constant within deployment- ie using the local file system in both cases)
Thank you.
I am asking because I have an externally referenced dll in my ssis package script that successfully executes with the package utility but not when deployed to the server agent within SQL server 2012 mgmt studio.
If you are sure that the agent service is running on an account that has proper permissions, check to ensure that you are executing the same runtime version for both instances. Your driver may be 64 bit and incompatible with 32 bit runtime and vice-versa.
There is an option in "execution options" of the agent job step that will allow you to select the 32 bit runtime, if needed.
If you are unable to get the "SQL Server Integration Services Package" job step type to work, you can change to using the "Operating system (CmdExec)" job step type and simply build a command using the utility executable (dtexec) and copying the info from the "Command line" tab of the utility. Some prefer this method of executing SSIS packages with the agent as it provides cleaner maintenance of the jobs. Searching the google for this topic will bring up articles like this: http://bi-polar23.blogspot.com/2008/06/ssis-and-sql-server-agent-choosing.html
Hope this helps.
I have created one SSIS packages, which pick the file from the Share point document library. its work successfully, once it execute through the VS project application.
But when i create a job in SQL Server Agent for this package then it does not pick the file and job getting fail.
Just for more update, SQL Server has been install in Cluster mode and using BIDS 2012 with SQl Server 2012.
You need to pass the login credential detail to SSIS package for picking the file from the share point document library,
for fixing this issue, You have to use "Net use" command like this link and create a one .bat file, and that .bat file called in SSIS package "Execute Process Task" tool.
By this command you can create the network map drive and pass the User name and password on the Share point document library.
Your "SQL Server Agent" (or the user you choose in the "Run as" dropdownlist of the Job properties) must have the rights on the SharePoint Server.
It works when you're running the package from VS because when you run a package in VS it's running with your own user rights (and you have rights on the SharePoint server).
I have a server that has a SQL Agent job setup to run a two part datawarehouse build and Analysis Services cube build. The job ran successfully until there was a problem with Management Studio and .NET framework 2.0 SP1 was re-installed. The first step in the SQL Agent job is unable to kick off the SSIS package. If the Agent job is started at step 2 it will run.
SQL agent service has been setup to use the Administrator account which is a domainh admin account and a sysadmin in the SQL Server security. The steps to troubleshoot SSIS package execution were followed from the link below.
http://msdn.microsoft.com/en-us/library/dd440760.aspx
The protection level has been set to DontSaveSensitive. The SQL Agent account has rights to run dtexec.exe and also setting up a proxy account did not resolve the issue. ZThe SSIS package will run if started manually from Management studio.
Redeploying the package and setting up the Agent job again does not resolve the issue and the package also throws the same error if run from the file system as opposed to the msdb location.
The error that the SQL Agent is throwing up is access denied by user domainname\sqlagentaccount.
Any further assistance on this issue would be greatfully appreciated.
Sounds like you need to poke around in dcomcnfg.
I forget the exact details but you need to set/fix some rights.
MS KB 2000474 found using a general search
I guess the account you use for Agent does not have enough permissions on the file system. Check the folders that were modified by the re-installation of .Net framework. If I remember correct the account should have access to the .net framework folders.