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
Related
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.
(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.
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'm trying to do some excercises from exam 70-515. Unfortunately I fail while trying to attach Northwind to a grid-control. It would result in:
NORTHWND.MDF' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported.
I use Windows 7 Home and MS Visual Web Developer 2010 Express. As fas as I understand this error, SQL Express must be an old version on my system. I downloaded and installed SQL Express 2008r2 from here. No effect. From other sources I figured out that I might need to change the instance name: Tools -> Options -> Database Tools -> Data Connections -> SQL Server Instance Name. There it is written SQLEXPRESS. I don't know what else I should insert there?
Turns out that deinstalling SQL Express and reinstall the latest version fixed the problem. I chose SQLSERVER2008 as Instance-Name while installing and set it in Visual Studio as described above.
Go to the Services control panel and look for a service named SQL Server (XXX) -- that XXX is the name of the instance that service is running. You just have to find the 2008R2 instance that you installed and type that into the "SQL Server Instance Name" box.
Might help to try to change the compatibility level, to make sure its backwards compatible.
Verify what level it is
USE VJ_DATABASE;
GO
SELECT compatibility_level
FROM sys.databases WHERE name = 'VJ_DATABASE';
GO
Then make it compatible with the older version
ALTER DATABASE VJ_DATABASE
SET COMPATIBILITY_LEVEL = 110;
GO
100 = Sql Server 2008
110 = Sql Server 2012
120 = Sql Server 2014
By default, Sql Server 2014 will change the db versions compatibility to only 2014, using the ## version you should be able to tell, which version Sql Server is.
Then run the command above to change it the version you have.
Additional step: Ensure you look at the accessibility of the DB is not reset, do this by right clicking on properties of the folder and the database. (make sure you have rights so you don't get an access denied)
I read this post but nothing helped me. Then I tried a few other options.
The way that I found that worked was to export the database and stored procedures from the original database. Then upload them into the second database(second computer).
Firstly export the DB content (data) - I used SQL server export data wizard. on the database you wish to export from right click then choose tasks, then export data. Follow the instructions and save in whichever format is best for you - I used excel for the data.
then to export the stored procedures rightclick the database name again. choose tasks and this time choose generate scripts. again follow the instructions of the wizard.
To import the data simply go to the second computer and right click the database you wish to import the data into. again tasks > import data. Follow the instructions to import all of the data from the database.
Finally to import the stored procedures, I opened up a new stored procedures command and dragged and dropped the script file that I had previously saved them in and dropped it into this window. The new stored procedure window filled with the entire list of my stored procedures. Finally change the name of the database name that will be used by the SP ( if this is different from the original DB name). (This is the first line USE [DBName]. then simply execute and the SP's will be fully restored.
This has helped me get my entire database up and running again very quickly. Hope this helps.
The SQL Management Studio is different than the SQL Server Version (or Database version). Example: At the current time, my work computer has SQL Server 2012 Management Studio but the SQL Version is 9.0 – which is SQL Server 2005. The SQL Management studio is only an IDE (Integrated Development Environment) and is NOT the same as the SQL Server version.
If when you try to Attach a Database, if you get an error similar to the following:
“The database 'AdventureWorks2008' cannot be opened because it is version 655. This server supports version 612 and earlier. A downgrade path is not supported.
Could not open new database 'AdventureWorks2008'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 948)”.
It means that the Database that you are trying to Attach was created with a Newer SQL version then what your computer has and you will NOT be able to use it. See if they have that Database that was created with the same or earlier version of SQL Server that your computer uses. In this case, I found the same Database that was created with SQL Server 2005 (Version 9).
A quick way to check what SQL Server version the computer is running, from the Windows desktop, go to Task Manager (Ctrl+Shift+Esc), click on the Processess tab, find and select the entry named “sqlservr.exe”, right click and choose Properties, click on the Details tab look at Product Version (Ex. 9….) or File Version (File version states the year and the version - Ex. 2005.9…).
Really this is the same error that i get, but until now i did not solve the problem!!
Go to Tools>Options>Data Connections, provided you have installed SQL Server Express 2008r2, leave the SQL Server instance name blank.
This happens when you are trying to use the SQLServer Express to connect to the MDF file. To remedy this issue, you need to go to Services.msc and turn on SQL Server services. You need to set the log on properties and when the service is started, you will be able to connect to the MDF file without any issues.
I am attempting to open a Crystal Reports 8.5 document, and when I try to set the database to the Production data server, i get the error "Pdssql.dll cannot be found". Googling, this is a common problem, but none of the fixes I tried seem to work.
This is a new computer. I do have SQL Server 2008 client tools installed, but I believe previously I had Sql Server 2005 client tools.
I attempted to install the SQL Server 2005 client tools, but that didn't go through due to me having 2008 installed. I require 2008 to do my job now.
Everything I search for says this is a 16bit driver, and I need to install the 2005 client tools. Unfortunately this cannot be done due to me having 2008. is there some sort of work-around I can do?
Thanks
Here is what I had to do if it helps--I had to retire a windows 2000 server so I needed to move a webapp which required Crystal Reports 8.5 onto a new server.
Since I couldn't locate the original installation runtimes (I don't know who developed or even uses this particular webapp) I had to copy all the crystal reports files over to the new server myself and register the required dlls. The crystal reports designer was working except it couldn't seem to make any connection to any of the database servers.
Then I found a folder that I had missed under C:\winnt\crystal which was filled with files such as p2ssql.dll p2lodbc.dll etc... turns out that P2SSQL.DLL is actually Pdssql.dll!
By putting all these dlls into a folder within my system32 path all my database connections within crystal reports were working again!
Did you try creating a DSN in the ODBC administrator? You would have to update the report to use the DSN instead of a "direct" SQL connection, but it should work. ODBC should do it's job and do all the SQL translation (talking to 2008 and just return generic data to the report).
I do not believe a direct connection from Crystal 8.5 to SQL 2008 would be possible though, because the technologies are almost 10 years apart.
Try to Download "ntwdblib.dll" and put in
Windows\sysytem32
if the system 32 bit or in
Windows \syswow64
if the system 64 bits