I have an SSIS solution with about 150 packages. Two of the packages consistently fail with an "Unexpected Termination" error when running in 64-bit. They succeed when running in 32-bit runtime.
The packages that fail writes some rows to the destination before failing.
The source and destination for all data flows is the local SQL Server databases. I use SQL Server Native 11 OLE DB drivers.
Both packages contain DT_NTEXT data types, but so do some of the other packages that succeed.
The are nothing in the ErrirDumps folder (C:\Program Files\Microsoft SQL Server\140\Shared\ErrorDumps). Also nothing in the Windows event log.
Below is an image of the dataflow task. The LKP component only caches 5 rows.
Any help or ideas would be much appreciated.
I had the same problem with my SSIS package. After upgrading from 2010 32-bit to 2016 64-bit, the package stopped working. SQL Server Job doesn't show errors, and even verbose error logging does not provide useful information.
My packages were importing a few different spreadsheets in parallel. After changing the tasks to serial processing (import the next spreadsheets after the first one is done), the package works again.
Before updating your SSIS package, I suggest you disable tasks in your package and find out the source of the error. But hopefully this helps!
I had a similar problem, or hopefully the same. The package could not be run using 64bit env and there were no logs either.
Just check your dotnet framework installation. There was a problem with file permissions at machine.config file within "Framework64" folder...
Related
I have developed a SSIS package which uses a 32 bit ODBC driver to connect to our legacy systems. I can run the package from Visual Studio, using Run65BitRunTime = False and it runs fine. However, when I deploy the package to the SSISDB catalogue on our SQL2014 box and select 'Run in 32 bits' from the Advanced tab of the config options I get the following error:
I have found quite a few posts describing this error but as yet failed to find a solution. One thread suggests checking the registry setting for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\120\SSIS\Setup\DTSPath.
For this we found it was pointing to ProgramFiles and not ProgramFiles (x86), which is where the exe resides. However changing this setting and restarting the services and server did not fix the issue.
TLDR; I am attempting to connect to a host and hitting "To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher". Does SSIS need to be installed on all Hosts for my package to succeed? Secondary question: If so, why would a manual execution from my dev machine work while the deployed/dtexec versions fail?
Apologies if this is a basic question (I am still steeping myself in all things SSIS and trying to learn as quickly as possible). Thanks in advance for any assistance you can provide!
I have a package that runs fine on my development machine (via Visual Studio). However, when I deploy the package out I encounter errors when attempting to connect to a MySQL database on a secondary host machine on the network. Taking a step back, I decided to attempt a manual execution via DTEXEC on my dev machine to attempt troubleshooting...
When executing this package through DTEXEC however, I encounter an error stating:
"To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher"
Looking at the log, it looks like the package is able to connect to Host 1 successfully and do some data manipulation (one of the 3 hosts; I know Host 1 and Host 3 have SSIS installed). However, when it attempts connection to Host 2, it fails with the aforementioned error. For the longest time, I thought this was due to the MySQL database I am trying to connect to (using .net Provider\MySQL Data Provider) but given the error above, it is possibly pointing to something else...
After doing a bit of searching I have located the following articles which may be related:
https://dba.stackexchange.com/questions/49786/error-to-run-a-ssis-package-outside-of-sql-server-data-tools-you-must-install
Getting error running SSIS package on non-SSIS Server
I know SSIS isn't installed on Host 2. The package is being executed from Host 1 and this host does have SQL Server and SSIS installed. Host 3 additionally has SQL Server and SSIS installed and I am able to successfully operate/connect on this host as well. The only host presenting a problem is Host 2 which does not have SQL Server nor SSIS installed.
Do all hosts have to have SSIS installed for connections to be made? Additionally, if SSIS does need to installed on Host 2, why would my dev machine succeed while the dtexec/deployed versions fail?
Again, thank you for any assistance you can provide!
The answer to your first question is "Yes", and that fact is the answer to your secondary question.
In short, SSIS packages are NOT self-contained executable files. They are more like .ini files that the SSIS Service reads, interprets, and executes. If the SSIS Service is not running on a host computer, then that computer cannot do anything with an SSIS package (the .dtsx file).
Your dev machine succeeds because it has Visual Studio, or BIDS, which is a developer's version of the SSIS Service engine.
I have a SQL Server Agent Job executing a file-system-deployed SSIS package via CmdExec & the 32 bit DTExec. However, the most recent version of the package version is not executing.
The change I've made is within a Script Task. I've made sure to Build within the VSTA editor before closing, etc.
I've verified this is the problem by putting the expected version in the command line parameters, so the task fails: /VERIFYVERSIONID "\"{1F870663-1898-4A30-B4A8-226817D1755F}\""
Is there a cache that can be cleared?
One approach would be to change the executiontype for the SQL job to be Operating System (CMDEXE) and provide the path to the dtexec file for SSIS to use as the executable.
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtexec.exe /FILE "c:\path\to\my\ssis\package\myssispackage.dtsx" /CHECKPOINTING OFF /REPORTING E
By calling the dtsx specifically you can point to the 32 or 64 bit version. You can also revert to a previous version of SSIS (dtexec) if you have those installed on your executing server.
I recently upgraded some of my packages to SSIS 2012 and had to use the new version for the packages to be executed by dtexec. That resolved my issue. Hope that helps.
Nothing to see here, move along..
I'm doing new child package testing on a server hosting multiple environments shared by my dev team, and we're in the process of shuffling things around. The job in question is one of a few identical ones and the path to the package got changed.
This is a 'master' package that dynamically executes child packages based on values read from a queue which is why it didn't occur to me to check the path.
Noob oversight.
We've got a a series of SQL Server Integration Services packages that copy data from a few MS Access databases into a SQL Server 2008 database. There is one parent package that calls the various sub-packages, and that parent package is initiated by a user that runs a .bat file that executes the package like so:
dtexec /f "\\networkshare\package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
This has worked fine for several years. Our IT department has begun upgrading our 32-bit Windows XP workstations to 64-bit Windows 7 and since they've upgraded the workstations of these users, the package has been failing, giving the error
-1071607037,0x,SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR. The requested OLE DB provider MICROSOFT.JET.OLEDB.4.0 is not registered -- perhaps no 64-bit provider is available. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
My workstation has not yet been upgraded from Windows XP and I'm still able to run the packages but my ability to postpone the upgrade is running out and I need to figure out a solution as soon as possible. I've found many articles and posts related to this in my efforts to resolve the issue. Among the things I've tried are:
After ensuring that the users had the Client Tools and Business Intelligence Development Studio installed and that the path is valid, changing the contents of the .bat file to specifically reference “C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\dtexec.exe” in the hope that the 32-bit JET provider would be used
Researched the Run64BitRuntime setting but this appears to only have an effect while debugging and won't help me
Researched adding the /X86 flag to the command line but according to the MSDN article on dtexec, this only has an effect if the SQL Server Agent is running the task
The last thing I've tried was to install the Microsoft Access Database Engine 2010 Redistributable and change the connection string from "Provider=Microsoft.Jet.OLEDB.4.0;" to "Provider=Microsoft.ACE.OLEDB.12.0;". I can't seem to get off the ground with this one. If I try to create a new connection in BIDS and set the provider to "Microsoft Office 12.0 Access Database Engine OLE DB Provider" and test the connection, I get the error "Test connection failed because of an error in initializing provider. Unspecified error".
I'm just about at a loss for what else I can try and looking for any help at all, even if it's trying the things I've already tried, maybe I've configured something wrong while trying them originally, not sure.
Any help would be immensely appreciated!
In SQL Agent job or by just executing the package by itself there is a tab called "Execution options", you can select "Use 32 bit runtime" option
By default, SQL Server puts the 64-bit version of DTEXEC in the path. The 32-bit version should be located somewhere like C:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn and would need to be called directly. I had the same issue with the ACE drivers and Excel files.
See this for more information.
I was able to run it successfully by changing debugging setting in project property page. Property to change is Run64BitRuntime -> set this to false.
Ok - this is probably a silly question but what the hell.
I've created a SSIS package with configuration and a deployment manifest. When I copied this over to the server and double clicked it, the Package Wizard returned an error - that Integration Services wasn't installed - bad.
But when I did an export data task via SSMS, I noticed I could save this task as a package. When I set up a job I noticed I could actually select an SSIS package to schedule - even though SSIS is not installed(!?!) Does this mean I could just point to my earlier package and schedule that?
If so, do you only need Integration Services installed in order to install packages within SQL Server - its fine to run them from the file system?
Cheers
Here is a good article on different ways to execute a package programmatically:
http://blogs.msdn.com/b/michen/archive/2007/03/22/running-ssis-package-programmatically.aspx