I've been able to successfully create an ssis package (.dtsx) file using the SSMS 'import data' option and the VS 2017 SSIS toolbox (SQL Server 2017). The package itself works and it reads a csv file and loads it into a database table. Simple. This is on windows 10.
I'm trying to run these packages on Win Server 2012 R2 (Azure VM) command line and it won't work (it does work from VS 2017) because the dtexec.exe files are all 32 bit. For the life of me I cannot get a 64 bit dtexec.exe file installed.
I've tried
the same procedure on windows 10 and it works. I create the package and then I can run it via dtexec /f "path to .dtsx"
I've tried to set the run time to 32 bit per (
SSIS 64 bit vs 32 bit)
But this is not an option in either the SSMS import data tool or VS 2017 SSIS Toolbox settings/properties.
I've come across this page
(https://www.sqlservercentral.com/articles/how-to-execute-an-ssis-package-from-the-command-line-or-a-batch-file)
But I'm not sure that turning this package into a 'package deployment model' is the way to go.
I've tried copying the 64bit dtexec and related files to the Win 2012 R2 machine but the dll and code is not registered.
When I try to install SSMS or SQL Express on the server I don't get options for customizing the install.
I've confirmed that the server is 64-bit.
I've tried an azure logic app but I simply don't like it that way.
These are some of the errors I'm seeing
Code: 0xC001700A
Description: The version number in the package is not valid. The
version number cannot be greater than current version number.
Could not create DTS.Application because of error 0x80040154
I would like to keep things simple and create an ssis package that can then be run at the server via a command line script that is scheduled. Why in the world is this so hard to set up on an Azure VM running Windows Server 2012 R2?
Below are a couple of more resources I've stumbled upon. Looks to me that the VS 2017 SSIS toolbox way of doing this is what MS wants people to use. How could it be that they make it so easy to create the workflow and store that into a package (the dataflow works on the Win 2012 R2 server inside of VS 2017) but when it comes time to roll it out and automate it everything falls apart? I must be missing something. Any help would be useful. How the hell do I tell VS 2017 to create a 32-bit compliant version of this package?
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017
https://learn.microsoft.com/en-us/sql/integration-services/lesson-1-7-adding-and-configuring-the-ole-db-destination?view=sql-server-2017
Related
I am trying to run an SSIS job which loads data from an Excel. I need to run the package in 32bit but that option is missing when I try to create the job.
This was happening to me as well, with Visual Studio 2019 on SQL Server 2019. I already had SSDT and Client Tools installed.
On the server, the version of Management Studio was a little older (v18.6) than the one on my desktop, which was working. I updated the server Mgmt. Studio to v18.6, 15.0.18338.0 and I could find the 32 bit check box.
I'm not sure if it's due to SSMS versions, but on my job, the location has changed tabs. FYI, I'm using SSMS version 18.12.1
I am using Visual studio ultimate 2012, SQL Server 2017 and Sql Server Data tools 2012. I am working with windows 10 64 bit.
My package consists of script tasks(c#) and Sql commands and it runs successfully from SSDT, but while trying to run my package from CMD i am getting
To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition (64-bit) of Integration Services.
If i make another empty package and try to run it then it runs successfully too.
Please help.
(1) Integration Services (Shared feature) installation
I think that the issue is that you have installed SQL Server Data Tools (SSDT) for Visual Studio but you didn't install the Integration Services (Shared feature) from the SQL Server Installation which is necessary to execute .dtsx packages outside of visual studio.
For more information check the following link:
SSIS Error – “To run a SSIS package outside of SQL Server Data Tools you must install…”
(2) Execute using dtexec(32-bit)
Another thing you can try is to execute package via 32-bit dtexec.
As mentioned in the following Microsoft Documentation:
On a 64-bit computer, Integration Services installs a 64-bit version of the dtexec utility (dtexec.exe). If you have to run certain packages in 32-bit mode, you will have to install the 32-bit version of the dtexec utility. To install the 32-bit version of the dtexec utility, you must select either Client Tools or Business Intelligence Development Studio during setup.
By default, a 64-bit computer that has both the 64-bit and 32-bit versions of an Integration Services command prompt utility installed will run the 32-bit version at the command prompt. The 32-bit version runs because the directory path for the 32-bit version appears in the PATH environment variable before the directory path for the 64-bit version. (Typically, the 32-bit directory path is :\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn, while the 64-bit directory path is :\Program Files\Microsoft SQL Server\100\DTS\Binn.)
More info at:
How to execute a package in 32-bit mode using dtexec.exe?
Also, similar issues was mentioned in other links, you can check them for more information:
SQL Server Central Forum - Run a SSIS package outside of SQL Server Data Tools you must install of Integration
Code Project - How To run a SSIS package outside of SQL Server Data Tools ?
MSDN - To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition of Integration Services or higher
To run a SSIS package outside of SQL Server Data Tools you must install Move File to Archive of Integration Services or higher
SE DBA - Error: “To run a ssis package outside of sql server data tools you must install [send successful email] of Integration Services or higher.”
Adding to Hadi's answer, the change would be to use the right version which in my case was to use
C:\Program Files\Microsoft SQL Server\130\DTS\Binn>
Instead of
C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn>
I had the same error and my integration services of 2017 was installed, so the suggested solution was not relevant.
i tried many options including uninstall and re-install, what solved finally was an upgrade to ENTERPRISE EDITION!
I found out that in a server where the dtexec ran successfully an ENTERPRISE VERSION was installed, while in the problematic server there was not an ENTERPRISE edition.
How did i find it? i ran the following in both servers:
run setup.exe file of SQL SERVER 2017 installation
on the left menu you will see "tools" - press the link
find: "installed SQL server features discovery report"
you will see in edition column an empty cell vs. "Enterprise Edition"
which is the successful one!
how did i upgrade in the problematic server?
run setup.exe file of SQL SERVER 2017 installation
on the left menu you will see "maintenance" - press the link
find: "edition upgrade"
follow the instructions, in my case since my organization had an automatic updated key i just pressed "next" a few times until a successful upgrade
good luck!
We recently updated our production SQL Server 2016 Enterprise instance from SP1 to SP2. We are currently on version 13.0.5026. Prior to the upgrade, a user with connect rights to SSISDB and proper rights on the Integration Services Catalog folder could deploy an ISPAC file successfully.
After the upgrade, the same users can still deploy to the SSISDB, but when you execute the .DTSX, the script task inside fails validation. If I deploy the exact same ISPAC as a sysadmin, there's no issue. The usual solution I've seen is to confirm that SSDT Configuration Properties are set to SQL Server 2016. We have verified this is set correctly prior to building the ISPAC.
I saw a similar issue when migrating from SQL Server 2014 to 2016 a couple years back, but the solution at that time was to give the Proxy account that runs the package modify rights to the C:\Windows\Temp folder so it can generate temp files. This new issue is hard to pin down, and I don't want to give out sysadmin just so others can do the simple deployment steps.
Any thoughts or suggestions are appreciated.
*******Update/edit************:
The server has a SQL Server 2016 deployment tool located under SQL Server/130/DTS/Binn - ISDeploymentWizard.exe. This deployment tool works. There is another identical wizard under the 140/DTS/Binn location, same name but 1 KB larger (assuming this is because SSMS is a separate install now, and I installed latest and greatest on server). This one fails deployment. I'm banging my head against the wall as to why one works but the other doesn't. Locally we all use SSMS 2017, and with that we get the 140/DTS/Binn ISDeployment file, not the 130 (since that's SQL Server 2016 and we're using SSMS 2017, which I thought was backwards compatible). Either way, this problem just started occurring and we've been on the same version of SSMS for a few months.
Image of the Execution information report from SSMS
Had resolved a similar issue with C# scripts recently. In short: don't use 140 version of ISDeploymentWizard.exe with MS SQL 2016. It apparently mangles something in C# code, or components' properties, and 2016 runtime stops recognising them.
In my case, a package with C# script source has started to throw the following error during the validation phase:
Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:
The version of C# source component name is not compatible with this
version of the DataFlow. [[The version or pipeline version or both for
the specified component is higher than the current version. This
package was probably created on a new version of DTS or the component
than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100
wrapper, Int32 lPipelineVersion)
The first comment here has helped me to ultimately identify the cause.
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 that runs fine from Visual Studio but doesn’t work on the server.
Executing under my security context produces the same results as a proxy account.
It's running a custom assembly
The server is running SQL Server 2016
The server has the shared components installed on a different drive (d:)
There is a script task that needs a licence key
Runs fine locally using Visual Studio 2013 (I edited 64 & 32 bit versions of DtsDebugHost.exe.config)
On the server I installed three dll's to the GAC & placed a copy in Program Files and (x86) \Microsoft SQL Server\130\SDK\Assemblies\
a.dll - MSIL
b.dll - MSIL
kernelx86.dll - X86
One of them wouldn't install to the GAC until I edited the GACUTILs config and put the below line in.
Then I edited the config files for running SSIS packages;
1. DTExec.exe.config - Command line execution
2. DtsDebugHost.exe.config - Visual Studio debugging
3. DtsHost.exe.config - SQL Server agent
Either one of the DLLs isn't being used or the licence key still isn't being picked up.
Any suggestions are appreciated,
Dan