Currently SSIS package 2012 is working fine in SQL server 2012 so we have migrated the objects into SQL server 2016 and the same package also converted into 2016 and deploying into SQL server 2016 but faced below error.
Batch File - We dont have dtutil in Program Files for 64 bit :
"C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\dtutil.exe" /FILE "G:\MSDB2016\MSDB2016\MSDB2016\Package.dtsx" /DestServer <> /COPY SQL;"MISSnOP_Test2016\Package" /Q > test1.txt
Error - test1.txt :
Microsoft (R) SQL Server SSIS Package Utilities
Version 11.0.6020.0 for 32-bit
Copyright (C) Microsoft Corporation 2012. All rights reserved.
Could not load package "G:\MSDB2016\MSDB2016\MSDB2016\Package.dtsx" because of error 0xC0011008.
Description: The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored.". This occurs when CPackage::LoadFromXML fails.
Source: Package
Note :
The same 2012 package is deployed in SQL server 2016 (MSDB), the SQL job is working fine but not triggered the packages (data is not updated into the audit table). The same package is working fine in manually through VS 2010 and VS 2015. I have tried lot of things but could not resolve this issue.
Please help me to resolve the same.
Related
We are moving an existing system from a SQL Server 2005 system. A component of that system was an SSIS project created with VS2005.
We installed SQL Server 2016 STANDARD EDITION in January. The database data files are on the E: drive.
We installed Visual Studio 2017 in January but didn't use it at that time.
We recently installed Visual Studio 2019 on the db server due to problems with file access when running VS2019 locally and using a VPN to access the network.
We just installed SSIS from the SQL Server Setup, realizing we were missing that component.
As a result of all these installations, dtinstall.exe & dtexec.exe are in the following folders:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\SSIS\140\Binn
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn
E:\Program Files\Microsoft SQL Server\130\DTS\Binn
E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn
E:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn
E:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn
E:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn
The dtexecui.exe is found ONLY in the following Folder:
E:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Binn
The two Visual Studio 2019 packages were developed in the C: drive on the server. They compile and execute correctly from within VS.
Each package has 3 Configuration Files (for test, preview and production scenarios).
Configured the 2 Packages' TargetServerVersion to "SQL Server 2016", due to a compatibility issue discovered upon installing the Deployment Utility.
Created the Deployment Utility using the Legacy Package Deployment Model.
Copied the Deployment Utility files from the C:...\Deployment folder to a folder on the F: drive on the server.
Ran dtinstall.exe to install the packages on the server. It created the files on the same drive where the database data files are:
E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Packages\Web Site Synch SSIS Project.
Executed the packages using dtexecui.exe, which as mentioned above, is ONLY found in the \150\Binn folder.
Here is the DTexec.exe command line that is generated by dtexecui:
/FILE "\"E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Packages\Web Site Synch SSIS Project\Products Upload.dtsx\"" /DECRYPT /CONFIGFILE "\"E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Packages\Web Site Synch SSIS Project\Test Products.dtsConfig\"" /CHECKPOINTING OFF /REPORTING EW
Upon execution (from within dtexecui), it gives an error in the final step, which executes WZZIP.exe to zip the Flat Files that were created in the preceding steps.
dtexecui error in WinZip step
The error message says: "Error: To run a SSIS Package outside SQL Server Data Tools you must install Standard Edition of Integration Services or higher."
I didn't really understand this message: We do have SQL Server Standard Edition. I assume the SQL Server Setup for this would install the Standard Edition of Integration Services.
I researched this error and found that it was often due to an incompatibility between the package version and the tool version, but I was at a loss as to how to resolve this in my scenario. The dtexecui error message gave no hints.
In the course of carefully documenting my issue for posting it here, I realized the problem might be that since I was using the \150\ version of dtexecui.exe, it is probably running the \150\ version of dtexec.exe, and that is the incompatibility.
I copied the command string generated by dtexecui and then ran it using the \130\ version of dtexec. It ran without error.
Here is the command prompt session:
E:>cd E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn
E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn>dtexec /FILE "\"E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Packages\Web Site Synch SSIS Project\Products Upload.dtsx\"" /DECRYPT /CONFIGFILE "\"E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Packages\Web Site Synch SSIS Project\Test Products.dtsConfig\"" /CHECKPOINTING OFF /REPORTING EW
Microsoft (R) SQL Server Execute Package Utility
Version 13.0.5026.0 for 32-bit
Copyright (C) 2016 Microsoft. All rights reserved.
Enter decryption password:
Started: 2:44:57 PM
Warning: 2020-04-29 14:45:01.31
Code: 0x80049304
Source: Unit Type SSIS.Pipeline
Description: Warning: Could not open global shared memory to communicate with performance DLL; data flow performance counters are not available. To resolve, run this package as an administrator, or on the system's console.
End Warning
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 2:44:57 PM
Finished: 2:45:06 PM
Elapsed: 9.344 seconds
E:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn>
Now I know that in my calling routines (stored procedures and the other application), I need to call this specific version of dtexec.exe.
I really hope this helps someone!
I have deployed a SSIS package created in Visual Studio 2013 to SQL Server 2014 SSIS catalog. But I can not run the package. Here is the error massage:
Package1:Error: Package migration from version 8 to version 6 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.".
check the .dtsx file for the following entry:-
<DTS:Property
DTS:Name="PackageFormatVersion">8</DTS:Property>
a value of 8 would indicate the package is written for sql 2014; a value of 6 indicates sql 2012.
The error message indicates that you are attempting to run a package written for sql2014 in a 2012 environment, which doesn't fit with what you are doing.
If the version is 8 and your sql is 2014, then you could try updating to SSDT 2015, and re-executing the package from there.
I think everything that might be relevant is described at SSIS package upgraded by deployment.
Basically even if your Visual Studio SSDT-BI and the server match perfectly, you still have to use the right ISDeploymentWizard.exe.
The logs corresponding to the failed job are as follows:
04/11/2014 06:40:00,LPR_New,Error,0,USPHND0088,LPR_New,(Job
outcome),,The job failed. The Job was invoked by Schedule 14
(LPR_New_Job). The last step to run was step 1 (Upload
Material).,00:00:00,0,0,,,,0
04/11/2014 06:40:00,LPR_New,Error,1,USPHND0088,LPR_New,Upload
Material,,Executed as user: nestle\ussqldbserver. ...00.5324.00 for
32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 6:40:00 AM Error: 2014-04-11 06:40:00.39 Code:
0xC001700A Source: Description: The version number in the
package is not valid. The version number cannot be greater than
current version number. End Error Error: 2014-04-11 06:40:00.39
Code: 0xC0016020 Source: Description: Package migration from
version 3 to version 2 failed with error 0xC001700A "The version
number in the package is not valid. The version number cannot be
greater than current version number.". End Error Error: 2014-04-11
06:40:00.39 Code: 0xC0010018 Source: Description: Error
loading value "3" from node
"DTS:Property". End Error Could not load package
"\usphnd0088\dataxfer\LPR\LPR New\UploadMaterial.dtsx" becau...
Process Exit Code 5. The step failed.,00:00:00,0,0,,,,0
Have you checked what version of BIDS the project file was built in? This happens when the sql server agent's version is different from the one used to build the project that the SSIS package lives in.
There is a suggestion to rebuild the project in the correct version of BIDS that matches the server agent used to run the job. One other option is to set the location/path of the DTEXEC file you want to use (depending on which version you are using).
References: MSDN / Package migration from version 3 to version 2 failed with error 0xC001700A. The version number in the package is not valid. The version number cannot be greater than current version number.
Per this blog: http://blogs.msdn.com/b/jason_howell/archive/2014/09/30/ssis-error-when-deploying-from-vs-2013-to-ssisdb-in-sql-2012.aspx
The underlying cause is that currently (Sept 2014 timeframe) SSDT BI 2014 for Visual Studio 2013 does not support SSIS packages for SQL Server 2012.
It is a common feature request, and the product group is well aware of the demand.
http://connect.microsoft.com/SQLServer/feedbackdetail/view/944882/ssdt-bi-2014-backward-compatibility-for-ssis-2012
At present SSDT for VS 2013 only works with SQL Server 2014. You have to use SSDT-BI for Visual Studio 2012 with SQL Server 2012 SSISDB.
To provide a newer answer, using SQL Server Data Tools 2015, you can set the Deployment Target Version for your integration project to 2012, 2014 or 2016 (It defaults to 2016 and will result in version number errors on 2012/2014 DBs until you set it correctly). I successfully deploy SQL 2012 integrations now from SSDT 2015 after setting to "SQL Server 2012".
I had the same problem. here is how I easily solved it without messing with Visual studio. Of course the management studio on my desk is the latest version so when I exported/Imported using my management studio i had the error.
Actually Remote desktop into the legacy server and export the SSIS Project from that version of management studio.
While on the legacy server connect to the destination server of the same version and import.
I also found some fancy stuff where I had some aliases in the configuration manager aliasing some decommissioned servers.
One of the aliases was using Named pipes, that protocol was turned off on the destination so I turned that protocol on.
Did step 3,4 for both the 32 bit and 64 bit, and of course RDP'd into the destination server to make those changes.
I'm upgrading our ETL solution and databases to SQL server 2012. I have tested this upgrade but we have a debate about running an SSIS 2008 package with the Job on the SQL 2012 instance. I understand that the 2008 R2 instance job runs:
Message Microsoft (R) SQL Server Execute Package Utility Version
10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 2:10:11 AM DTExec: The package execution returned
DTSER_SUCCESS (0)...
and the 2012 instance job does an in-place upgrade of the packages and runs:
Message Executed as user: xxxx. Microsoft (R) SQL Server Execute
Package Utility Version 11.0.2100.60 for 64-bit Copyright (C)
Microsoft Corporation. All rights reserved. Started: 8:29:18 AM
DTExec: The package execution returned DTSER_SUCCESS (0). Started:
8:29:18 AM Finished: 8:59:46 AM Elapsed: 1816.76 seconds. The
package executed successfully. The step succeeded.
My question is this: Are there any reports of failure for such scenario and is it safe to assume there is a backwards compatibility?
From this page, DTExec 2012 converts earlier version packages in-memory to 2012 format. It is conceivable that the conversion could fail, however, it should be possible to test the packages, and if they run successfully once (i.e. convert successfully) then they should do so every time. Their behavior should be similar to a high degree, but I would not expect complete equivalence in all circumstances.
The most likely scenario for conversion failure is if the package includes third-party components that are not available for SSIS 2012.
I would not assume that a package can be run by a later version of DTExec without testing, but if it runs successfully once, there is a high probability that it will run successfully every time.
Not 100% backwards-compatible. E.g. a SSIS 2008-edited package that extracts data from flat file and doesn't specify row & column delimiters will work in 2008, but if you run that package on a SSIS 2012 server, the empty row & column delimiters will cause the extract to go nuts, it will import zillions of columns/rows (because it never finds a column/row ending). Big issue for me, currently.
There is one case I've found an issue with this that I wanted to share:
If you process the SSAS Cubes in SSIS 2008 packages, In rare cases the SSAS database connection provider won't work with the back dated version. See this link
When I try to execute a package which uses the Scripting Component object I get the following error:
Error: 2011-07-22 09:16:42.25
Code: 0x00000003
Source: {Task Name Here}
Description: There was an exception while loading Script Task from XML: System.ApplicationException: The VSTA designer failed to load: "System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component`enter code here`
I am running on a database server that has both SQL2005 and SQL Server 2008 R2 (RTM) - 10.50.1720.0 (X64).
I tried to execute the package using both the 32 and 64 bit versions with the same result.
I originally had an issue on my development machine where the Visual Studio for Applications Designer was not coming up when I tried to use the Scripting Object within an SSIS package for the first time. i resolved this by installing the latest SP for Visual Studio. Obviiously, loading visual Studio is not a possible solution to resolve this issue on a SQL Server.
Sugegstions?
Some Googling suggests you're executing a 2005 package with the 2008 runtime. Assuming that's the case, you can either use the 2005 runtime or upgrade the package.