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
Related
I get this error in Management Studio. I don't know what the reason is. I tried repairing SQL Server, but still the issue is not resolved. I read a lot of articles about this, but I don't know how to do this with registry keys.
How to solve permissions issue?
As James suggested, it's time to use a later version of SQL Server Management Studio.
If you can run the latest (version 18.4), that would be good. It still has support for SQL Server 2008.
However, it has more recent dependencies. If you look at the list of dependencies, you might decide that an earlier version would be better on the older system. SSMS 18.4 was based on a more recent Visual Studio shell. SSMS v17.9.1 is also available for download still, works fine with SQL Server 2008, and uses the older shell, so you might have less friction when trying to install it.
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
I have installed SQL Server 2014 and Visual Studio Professional 2015. So, does that mean it already has SSMS pre-installed with it, or it needs to be done separately.
My need is: Report generation using SSMS, from data coming from query behind SQL Server.
So, what needs to be exactly done to configure SSMS into SQL Server with VS 2015.
Upon deep diving even more, got the answer.
Option One: Google for 'SQL Server Data Tools' installer, compatible with your VS. Run the Installer.
Option Two: Open Visual Studio 2015 - Tools > Extension and Updates. Find/Search for 'SQL Server Data Tools' update option. Run it.
I'm still not sure if there comes a complete package of Visual Studio along with Data Tools, but I don't think it does. As we still need to add certain packages into VS Installer as per need.
I'm using Visual Studio 2015 to create a simple SSIS package. The data source is a DB2 database, and I'm using an ODBC driver on my workstation to connect to DB2. The target is SQL Server 2014.
The package runs fine locally, but whenever I run it on the server, I'm having trouble with the ODBC data source. The driver on the server is the exact same one with the exact same name as the one on my workstation.
To get the package into the server, I've imported the dtsx file into SSIS in Stored Packages. I've also tried to deploy the project to the Integration Service Catalog, but I get one of these failures related to the ODBC source when doing so --
The version of ODBC File Source, clsid {xxx} is not compatible with this version of the Data Flow.
The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "ODBC Source;Connector for Open Database Connectivity (ODBC) by Attunity; Attunity Ltd.; All Rights Reserved; http://www.attunity.com
I've also tried using a file based ODBC source instead of a system one with that file in a shared folder on the server. Again, it runs fine in VS but not on the server.
I've looked at the dtsx file (xml based) and I suspect that there is a conflict with the DTSID for the ODBC driver. I'm not sure how that works but it seems like that ID would be unique for each computer and that SSIS is getting is trying to use the workstation's DTSID on the server.
I'm a bit new to SSIS and Visual Studio so I'm hoping I'm assuming there is a straightforward way to run packages developed on a workstation at the server without these hangups. I just can't find anything specific to this problem anywhere.
We do not have VS or SSDT installed on the server.
EDIT: I added a second sentence in the 2nd error message above. It refers a connector provided by Attunity, which is something I don't understand. The ODBC driver installed on the system is from Data Direct. The CLSID returned in the error message is also associated with an Attunity connector in the server's registry.
There are no ODBC drivers from Attunity showing up in either of the ODBC managers, so it's possible that these are somehow part of a default install or were installed when our server used to have SSDT and VS installed directly on it and were never uninstalled. Or, something else?
I have resolved this issue by changing the Deployment Target Version of Integration Services project in VS in my case from SQL Server 2017 to SQL Server 2016 (the target SQL version). Hope this helps. Old quesition, but came up first in google when I tried to solve my problem.
In my case this issue was caused by deploying an SSIS project to a 2016 server using SQL Mgmt Studio 2017. Once I redeployed using SSMS 2016, it resolved the error.
VS or SSDT by default uses 32-bit drivers, so check there is option when you execute for 32-bit. Or install both 32-bit and 64-bit driver and create ODBC with same name.
This is what i do usually for ODBC connections in SSIS -- create connection in both 32-bit and 64-bit.
So create one with
C:\Windows\SysWOW64\odbcad32.exe (32-bit)
and one with
C:\Windows\System32\odbcad32.exe (64-bit).
I had this same problem when executing my package in SQL Server Agent. I resolved it by turning on the Execution Options "Use 32 Bit Runtime" flag in the agent step. Drove me nuts for a few days, hope this helps.
check the version of your solution vs the SQL version of where you are deploying. I had this issue and matching up versions fixed the problem. My solution was 2017 but the SQL box was 2016. I had to change the solution to 2016. cheers!
In my situation I was having this error and I switched to using the 32-bit version. My initial test worked, then I redeployed using a the project I was working with and I got this error again, even though I had switched Execution Options "Use 32 Bit Runtime" flag.
It ended up that I was having problems with my ODBC Data Source. I was using IBM Informix driver and it was having an issue with the chosen locale. I changed it to use the server's specific local and tested its connection. That then worked and my SSIS package worked on the server.
In another situation with this same Informix driver, I had the database name, slightly incorrect and that gave me this same error.
I am using Visual Studio 2012 with SQL Server 2012 Data Tools installed. For some unexplained reason, my workstation will only run my SSIS code in 32 bit mode. Here is a dummy data flow I built for testing purposes:
Here are my settings:
It only runs DTSDebugHost.exe *32.
I am at my wits end trying to figure this one out. What do I do to figure out why it is not running just DTSDebugHost.exe (the 64 bit version)?
This happens because VS 2012 is checking to see if VS 2010 ULTIMATE is installed. It just looks for a registry entry.
Solution:
Open Regedit
Browse to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\11.0\
Create a Key called premium
Create a Key called ultimate
Browse to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\10.0\
Create a Key called premium
Create a Key called ultimate
Restart VS 2012.
Now it should work in 64-bit mode when you debug.
Ran into an almost identical problem and solution with SQL Server 2014 Enterprise, after installing SSDT-BI for VS 2013.
On a side note, I tried using the 64-bit debug host in SSDT-BI VS 2013 on two separate installs. One
where a full instance of SQL Server 2014 Enterprise was already
installed (with 64-bit debug host installed and verified) and another
where no previous SQL Server components had been installed at all. I
wanted to ensure that the "no debug with 64-bit runtime" issue was not
simply due to a missing 64-bit debug host or that the 64-bit host was
not installed as part of SSDT-BI for VS 2013 (It is not. It's part of
the full SQL Server itself, Integration Services (Shared Feature).
Per this thread on Social MSDN, adding the following registry key was what got the 64-bit debug host working for me:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\11.0\professional