I have created a SSIS sequence connecting to Postgres via ODBC 32bit - debugging this via Visual Studios all connects and works.
I deployed to SQL Server as an Integration Services Catalog and I can execute my 3 packages manually (marking the execute as 32bit runtime).
My problem now is when I create a Job via SQL Server agent and I define each step to execute as 32bit runtime, it complains about:
ADO NET source has failed to acquire the connection: the specified
DSN contains architecture mismatch between the driver and application
I have trolled the net with everyone saying 'make sure 32bit runtime is checked', 'ensure that in Visual Studios you say false to run in 64bit mode' but feels like I have missed a trick somewhere and I am baffled.
If anyone has any insights please?
Visual Studios 2015
SQL Server 2016
Thanks
Raj
I Answered one time this question, but I add 4 step.
If I good see you didn't do the 2 step?
There several steps to run a SSIS package in 32 bits:
Check if ODBC is created in 32 bit. Real odbc 32 bit administrator is in folder C:\Windows\SysWOW64.
Check if SSIS package has cheked run64bitruntime property FALSE.
Check if SQL Agent property 'Use 32 bit runtime' checked.
Check if ODBC Created in ODBC Administrator in System DSN tab - Because if You create in User dsn tab just your user will see that odbc.
Related
My SQL Server 2019 Enterprise is up and running on a Windows 2019 Core vm. Connections to SQL Server databases are A-OK.
I have installed the OLEDB driver OraOLEDB12.dll via the oui.exe in the ODTwithODAC122011.zip.
I checked only the Oracle Provider for OLE DB in the Component Name list.
It created the appropriate TNSNAMES.ORA file from the info I provided.
The installer added the appropriate paths to the environment var PATH.
After restarting the Windows 2019 Core VM, and reconnecting SSMS v18.8 to the SQL Server I could not see the provider in the Server Objects, Linked Servers, Providers list.
So I ran regsvr32.exe and got back DllRegisterServer in OraOLEDB12.dll succeeded. So I restarted the VM again, and reconnected to my SQL Server and still no joy.
What am I missing here? I've search through lots of google links, on StackOverflow itself and am finding the same results, path issues, registry issues, 32/64 issues. Our Ent SQL Server is x64, our SSMS locally is X64, the Oracle driver is x64.
Did you try to install more than one Oracle client? Oracle OLEDB driver can exist only once (i.e. once each for 32-bit and 64-bit).
Version of Oracle OLEDB driver must match exactly the Oracle client.
Maybe have a look at my Oracle Connection Tester, this may give you an indication whether your Oracle OLEDB driver is properly installed.
Gentlepersons,
My apologies, I did indeed install the 32 bit driver when I thought I was installing the 64 bit.
Have deinstalled (as Oracle calls it) the previous and am moving forward with the correct installation.
Again, my apologies for wasting time.
G
I'm working on a SSIS package which I've been developing inside Visual Studio Community 2019 (VS). I have installed Integration Services to develop the SSIS package.
The task of the package is pretty simple, connect to a PostgreSQL datasource via an ODBC connection and then perform a lookup to identify new and updated fields and pass these into a MS SQL database via an OLE DB connection. When I run this package from both VS and via cmdp using dtexec.exe it runs successfully without any error (yay).
I run into a problem when I try to execute this package after deploying it from VS using the Deploy Package Wizard to SSISDB on MS SQL Server(2016). The errors can be found in the image below. Please note that I have selected Target Server Version SQL Server 2016 so there should be no compatibility issues between the package and server.
I have read that there may be a compatibility issue between 64 & 32-bit. However, I have no idea how to configure this from within SSISDB. I did however, attempt to execute the package with run64bitruntime set to "false" (done inside vs) and "true" with no change in result. my version of SSMS 2016 is running 64-bit.
I should also add that I'm connecting remotely to SSMS 2016 to run the package from SSISDB, remote connections is set to true for this server.
Please let me know if I can supply further details to help debug this. Thank you.
(Note: this is my first post please bear with any mistakes in my presentation)
My issue is that I have a very simple SSIS package using the Microsoft Oracle Connector (created by Attunity) which executes fine within Visual Studio 2015 on my laptop, but throws numerous errors when deployed to either SQL Server, or when attempting to run from the command line. I've tried various links I've found here and elsewhere but I still cannot get this to work.
I am a complete newbie on these tools, I am coming from an Oracle and .NET background, so I may be missing some basics here.
Laptop setup is: Visual Studio 2015, ODP.NET 64 bit, 64-bit Oracle Client, MS Oracle Connector by Attunity 5.0 64-bit, Sql Server Data Tools for VS 2015, Sql Server Management Studio 2016 - 13.0.16106.4.
On the database server: SQL Server version is 2016 (SP1) - 13.0.4001.0 (X64)
Developer Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 , Oracle 64-bit client, SSIS, and MS Oracle Connector by Attunity 5.0 64-bit version.
I'm attempting to populate 3 SQL Server tables from 3 corresponding Oracle tables.
I have a very simple integration services project in VS 2015: 1 control flow item, with 3 data flows - all 3 run a simple SELECT against the same Oracle database with a connection manager to that DB, each one reads a different table, and populates a different SQL Server table (using the OLE Destination object), all 3 Oracle tables are in the same database instance, and SQL
Server tables are in the same database.
The project runs fine from my laptop within the VS IDE, all 3 feeds run in parallel and populate the corresponding SQL server tables as expected.
However, I'm getting numerous error messages attempting to execute the package using other methods. Googling around has not helped to clarify things - I think I basically understand the error messages, but I'm unclear on how to resolve them.
DTEXEC - I copied my .dtsx file for the above project to the C:\TEMP folder server where SQL Server resides, and I ran the 64-bit dtexec utility as follows:
F:\Program Files\Microsoft SQL Server\130\DTS\Binn>dtexec /file c:\temp\package.dtsx > c:\temp\dtexec_errors.txt
Please see images below for errors I'm receiving.
SSIS DB catalog - Created the SSISDB catalog under 'integration services catalogs' folder in SSMS. Within Visual Studio I right clicked the package and selected Deploy . After deployment, right clicked the package in SSMS, picked 'Execute'. Received several similar errors to what is shown in the screen shots.
Thanks in advance for any advice, pointers, assistance. Also note that from Oracle to SQL server I plan to do little to no transformation, plus this solution will eventually be used for possibly upwards of 200+ tables, if there is a better or easier way that can be automated and gets similar high performance I'm open to hearing it.
Windows Server 2012
SQL Server 2014
Visual Studio 2013 Professional
SpiceWorks 7.5.00101 / SQLite 3.7.15.2
I am trying to connect SQL Server / Visual Studio to the SpiceWorks SQLite database so I can make a report showing the currently open tickets and who is assigned to them. This report is for the front desk receptionist so she can refer ticket creators that call in to the right person in IT. We don't want her to be able to see potentially sensitive data within the tickets.
I cannot get the connection to work!
I have tried both the 32 and 64 bit sqlite odbc drivers from here: http://www.ch-werner.de/sqliteodbc/
I use the C:\Windows\SysWOW64\odbcad32.exe to create the 32bit ODBC DSN using the SQLite3 Driver
I use the C:\Windows\System32\odbcad32.exe to create the 64bit ODBC DSN using the SQLite3 Driver
When I attempt to use the 32bit DSN to create either a Linked Server OR when used in a SQL Report (SSRS) as a DataSource I get this error:
The specified DSN contains an architecture mismatch between the Driver and Application
Which is supposed to mean that I used the wrong odbcad32 to create it - but I didn't (I've recreated this damn thing several times)
When I attempt to use the 64bit DSN I get this error:
IM006[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
All I can find is a HotFix for this reported error
https://support.microsoft.com/en-us/help/822841/fix-setting-of-connection-attribute-fails-when-you-use-connection-pool
however when I tried to instal the hotfixes they error saying they cannot determine the version of Data tools.
I have tried this on a Windows Server 2008 where the SpiceWorks software/database is installed, and from our Windows 2012 w/SQL Server 2014 using the fully qualified path "\ \spwrks\c$\Program Files (x86)\Spiceworks\db\spiceworks_prod.db" and get the same results.
I have tried pointing to the production database and to a copy of the database.
I have tried to uninstall all of the SQLite drivers and start from scratch. When the 32bit one fails, I uninstall, reboot, and install the 64bit one and it fails.
A very weird part to this is if I create a Server Explorer > Data Connection inside of Visual Studio 2013 pointing to the 32bit DSN , I can see all of the tables, create and execute a query against it without any problems.
Once I publish (deploy) the SSRS report and try it from the browser I get the " The specified DSN contains an architecture mismatch between the Driver and Application" error inside the browser.
This is driving me nuts. Help!
I have tried following the instructions on these links:
https://community.spiceworks.com/how_to/128624-export-spiceworks-sqlite-data-to-ms-sql
https://community.spiceworks.com/how_to/2271-create-ms-sql-linked-server-to-the-spiceworks-sqlite-server
https://community.spiceworks.com/how_to/28362-view-the-spiceworks-database-and-create-sql-reports
https://community.spiceworks.com/topic/132253-how-do-i-generate-a-spiceworks-report-using-sql-server-2008-reporting-services
Just an update
I have made a SSIS Import job that first copies the existing SQLite database, so I don't mess with the production, then imports the two tables I need (tickets and users) into the 2014 SQL Server. Then, I want to run a report off of those tables.
It seemed to work when I ran the job inside of Visual Studio, but once I tried to schedule the job with SQL Agent it failed to connect to the ODBC. Which made me think of a permission problem since running it inside the SSIS works. I went back to the SpiceWorks folder and database and set permissions to Full Control for Everyone just to see, but it still doesn't want to connect.
As, I have been trying to get it to work; just an hour ago, my production and copied SpiceWorks database became corrupted - not sure if copying it made it happen or what. The whole thing is very... "finicky". I wasn't writing anything to it, just trying to connect and do 2 simple SELECT statements.
Luckily, I had backup copies of the SpiceWorks database and was able to restore it.
I've never had so much trouble just trying to get data from a database!
After assistance from Robert with Microsoft, the solution was to disable the Run64BitRuntime option under the Property Page for the SSIS Project (right-click on the Project, select Properties, then under Configuration Properties > Debugging, set Run64BitRuntime to False) , because the SQLite is 32bit.
More information can be found here:
http://help.pragmaticworks.com/dtsxchange/scr/FAQ%20-%20How%20to%20run%20SSIS%20Packages%20using%2032bit%20drivers%20on%2064bit%20machine.htm
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.