I developed an SSIS package about 6 months ago to migrate a number of access databases into SQL server. I opened the package yesterday to go through another run and noticed a few (X) error indicators. Upon further investigation, the connection managers produced the following error:
The specified provider is not supported. Please choose different
provider in connection manager.
The connection manager then opens, but the previously selected provider is no longer listed. Investigating the text in the project file, I was previously using:
Microsoft.ACE.OLEDB.15.0
Recalling that I did have to set the Run64BitRuntime to false in order to use the 32 bit providers, I double checked the Project Properties -> Configuration Propeties -> Debugging -> Run64BitRuntime setting, which had reverted to True. I switched to false, saved, exited and reopened, and the value had again reverted to True. Several other tries produced the same result. At this point, I believe that is the issue, but haven't yet found a solution.
For full disclosure, the package was developed on SSDT-BI for VS 2012, and I'm now using SSDT-BI for VS 2013. I've attempted to create a new package in case there was an issue there, but the same thing happens with a new package. I also upgraded my Office installation and now have version 16 of the Microsoft Access Driver (*.mdb, *.accdb) listed in ODBC (32-bit) instead of version 15.
Any ideas?
EDIT 1: An access driver is not listed in the provider list within the Connection Manager, but is listed in ODBC 32-bit providers. The Jet 4.0 provider fails with "Unrecognized database format"
EDIT 2: Ran into some posts that indicated if the provider isn't listed VS may be running in 64 bit mode. I doubled checked to verify it is running in 32 bit mode (as shown in Task Manager). Maybe my issue is that the provider isn't showing up at all?
EDIT 3: Reinstalled SSDT-BI for VS 2012, providers are still missing.
EDIT 4: I've tried running the package from VS as well as from the SQL server. The package was previously able to run in both places.
EDIT 5: Decided to try simple ODBC connections instead of the OLE DB provider by adding a new User DSN. Receiving this error:
ODBC driver for Microsoft Access installation problem: Unable to load odbcji32.dll
Which lead me to this link, which claims the recent Microsoft Office updates are to blame. Going to try installing the Office 2013 runtime.
Unfortunately, in this case, a recent Microsoft Office update was to blame. Installing the Microsoft Access 2013 Runtime resolved the issue, found here. The Microsoft Access 2016 Runtime may also work, found here, but for me it produced an error stating:
Windows Installer and Click-to-Run editions of Office programs don't get along for this version...
Related
I am using SSIS with Visual Studio 2019 for creating and deploying packages on SQL Server 2019. Initially when my package was running on SSDT I deployed it on SSMS Integration server but there was no output.
So, I Checked in Visual Studio 2019: Project -> Project Properties -> Configuration Properties -> General -> Target Version, which was set to SQL Server 2022, So I changed it to SQL Server 2019.
When I tried to run the package again in Visual Studio 2019 I got this error:
Failed to load the package "Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.Sql2019.IDTSApplication160'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{037FE238-12C5-4313-AE13-9E116E90ACEA}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).".
I tried registering the C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\DTS.dll using regsvr32 which shows success, but I am still getting the same error.
I also tried registering Microsoft.SqlServer.DTSRuntimeWrap.dll using gacutil.exe, still no luck.
Can someone tell me why am I getting this error and how to solve this.
Thank you in advance.
here is the workaround.
Here is the workaround: Solution Explorer -> right click project ->properties->debugging->Run64bitRuntime->set to false.
taken from https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects#:~:text=SSIS%20Execute%20Package,set%20to%20false.
I had the same problem with my VS 2019 after update to SSIS Projects 4.0. If possible, uninstall this version and install the latest general availability (GA) version 3.16, which can be downloaded here:
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
https://ssis.gallerycdn.vsassets.io/extensions/ssis/sqlserverintegrationservicesprojects/3.16/1645603822968/Microsoft.DataTools.IntegrationServices.exe
It solved the problem, you can run in 64bit runtime after downgrade.
I have only updated SSIS extension 3.16 to 4.0. I got same error. You should change configuration properties from right click project ->properties->debugging->Run64bitRuntime->set to false.
After that when i want to initiate VS, i got this warning '../Visual Studio 2019.lnk side by side configuration is incorrect'. I resolved the problem through repairing of SQL Server Integration Services Projects on Control Panel-->Programs and Properties.
I had the same problem start after updating Microsoft Data Tools Integration Services VS extension because of prompt by VS. The upgrade was to v4.0 which is not yet generally available.
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
On that page it states that "Version 3.16 is the latest general availability (GA) version, which does not support target server version SqlServer2022." There you will find a link to v3.16.
Uninstall v4.0 which, given how recently it was released, is probably still in your downloads folder, otherwise use Extension Manager. Then download and install 3.16. Be warned, both the uninstall and retro install were extremely slow.
Without a reboot, I opened the project and the package that failed with v.4.0, ran first time without problem.
Hope this helps somebody.
I have .xlsx file with 27,000 rows. When executing the SSIS package on the server I get the above error. I have tried running the package in 32-bit mode, it did not work. Microsoft does not have a good explanation. I have installed access driver on my machine and on the server.
Assuming that you tried running in 32-bit, and you downloaded Access Database Engine and the issue is not solved
This is caused by a windows security update, this is noticed in the Microsoft Support article, also they provided patches link.
There is a similar question on MSDN about this issue, read the accepted answers:
Unexpected error from external database driver (1)
Side Note: Try opening the Excel and saving it as new Excel workbook to ensure that the excel is not damaged
Remove the Ace Oledb driver 10 and install Ace 2016 version .The Security patch Microsoft provided in October 2017 is causing this issue. Test your SSIS package locally ,if everything is fine install Ace 2016 version on your server .
Here is the download link:
Microsoft Access Database Engine 2016 Redistributable
This issue is caused if the Excel file is in Read-Only mode. Changing the Read-Only mode will fix the issue.
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.
I was trying to use Team Foundation Server 2012 with Sql Server Management Studio 2012. I installed the Microsoft Visual Studio Team Foundation Server 2013 & 2015 MSSCCI Provider 32-bit and choose it as Current source control plug-in under tools -> Source Control -> Plug-in Selection of SSMS.
The problem is when I create/open a solution, for the very first time, and try to add a solution to source control from file -> source control -> Add Solution to Source Control a dialog box appears asking to connect to tfs once connected and location of server is specified on server and ok button is pressed it shows a warning that my workspace is a local workspace and local workspaces do not work properly in MSSCCI. It asks if I want to change it to server workspace once I click on Yes
I get the following error
Unexpected error encountered. It is recommended that you restart the application as soon as possible.
Error: No such interface supported
File: Vsee\internal\inc\vscomptr.inl
Line number: 259
Trying again yield this error message as soon as I choose Add Solution to Source Control.
I have tried some of the hotfixes provided by Microsoft from the link :
https://support.microsoft.com/en-us/kb/2727824 but they do not install on my machine saying that my SSMS version is newer.
How can I get this problem resolved ?
As described in this article - Team Foundation Server 2012 brought up a change in the workspace options bringing a new type of workspace – a local workspace. A local workspace is an improvement in offline work and it allows performing a number of source control operations without the connection to Team Foundation Server.
For more information about server workspaces vs. local workspaces refer to the following article: http://blogs.msdn.com/b/phkelley/archive/2013/05/29/server-workspaces-vs-local-workspaces.aspx
The article states that Microsoft continues to fully support the older kind of workspaces (from VS/TFS 2005 - 2010), but they now call these “server” workspaces. In the VS/TFS 2005 - 2010 documentation there is no mention of these workspaces ever being called “server workspaces” – because before the existence of local workspaces, there was no need to have a special name for them - they were just “workspaces.”
Hope I helped.
I am using TFS Online (Visual Studio Online), SQL Server Management Studio 2012, Windows Server 2008 R2, and installed Microsoft Visual Studio Team Foundation Server 2013&2015 MSSCCI Provider 32 bit. I can add new solution in SSMS and add to source control with no issue. You might want to
1. go back and create the server workspace FIRST in Team Explorer 2012.
2. Then re-create the solution (Make sure you check the Add to Source Control),
3. then select the TFS with the correct server workspace.
4. from Solution Explorer, right click on the project and add existing items.
Hope it helps