I am using the 64-bit version of SQL Server 2016 Express, trying to connect to a 32-bit Pervasive SQL v10 database. I am setting up a Linked Server in SQL Server via ODBC connection, but I am receiving this error that has given me a lot of pain in the past:
The specified DSN contains an architecture mismatch between the Driver and Application
I had a similar issue not long ago trying to connect to a Microsoft Access database, but with help here I was able to obtain the 64-bit ODBC driver for Access. However, there does not seem to be one for Pervasive v10 at all, only for PSQL v11+, which does not help me in this case.
Previous question: SQL Server Linked Server to MS Access - DSN Architecture Mismatch Error
So if anyone has a suggestion for connecting to a 32-bit client from a 64-bit SQL Server installation, when there does not exist a 64-bit ODBC driver for this client, please let me know.
One of the suggested solutions was to use an OLEDB link instead (but no details provided on this, and I'm not sure how it would differ from the linked server I am already trying to create, which is already using OLEDB).
There was also mention somewhere of installing an entirely separate 32-bit SQL Express client, and chaining an additional ODBC link to point to the first one, but I would rather avoid all that overhead if possible, especially since this is a production server that is already running Sage 50 in addition to our own software and web services with SQL Server...
Other details: The client that is built on Pervasive SQL v10 that I am trying to connect to is Peachtree 2017 - Sage 50. This is all running on Windows Server 2012 R2 Standard.
More reading here:
https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=12693&sliceId=1&cmd=displayKC&dialogID=50216&docType=kc&noCount=true&isLoadPublishedVer=&stateId=50217&docTypeID=DT_Article&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
https://www.experts-exchange.com/questions/23995371/Installing-Pervasive-SQL-Client-on-Windows-2008-64bit-missing-ODBC-Driver.html
Edit:
Thanks for the comments! After further investigation... it looks like this IS actually PSQL v11, not v10. Now, I'm not sure why the 64-bit ODBC driver is not already installed... but I am looking into this now...
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 have "inherited" a computer that has multiple ODBC driver's installed on it. Before I go removing anything, how do I tell which driver SQL Server is actually using? Does it just use the most updated one?
I am running SQL Server 2014, version 12.0.5207.0 (64 bit). I am also using SQL Server Management Studio 2017, version 17.5.
Additional question - I am planning to update the ODBC driver to 13.1, would I install the 64 bit since the server is 64 bit? When I look at the ODBC data sources the drivers are installed in both the 32-bit and 64-bit dialogues, so I am a bit confused. Total noob question, I realize, but I am very new to this.
That's not an easy answer. Let's break it into parts.
What driver is being used? The one the application requests. A driver is used by a client application to connect to the server, and the client application is the one that has the final say. You can look at the ODBC data sources configured in the machine to see the driver, but an application might not use an ODBC data source and instead embed the driver name into the application or some configuration file.
How can you tell? One way is to uninstall a driver and see what breaks. Usually not a good plan. Maybe you can use Process Monitor and check if any process load the drivers, but not Always feasible. If in doubt, leave the drivers alone. They are usually small and don't tend to cause trouble on their own.
As for SQL Server database engine and SQL Server Management Studio (SSMS), they normally don't use ODBC drivers. SSMS uses a .NET provider to connect to SQL Server. SQL Server database engine can use an ODBC driver if you have a linked server to another server.
If this is a database server and not an application server, chances are most drivers are rarelly used. If this is an application server, I'd leave the drivers alone. If it's a workstation, probably leave them alone too.
As for the new driver version, you need the 64-bit package to install, and it will install both 32 and 64-bit drivers. The reason is a 32-bit need a 32-bit driver, and a 64-bit application need a 64-bit driver. It's not the server bitness that matter in this case.
We have two database servers, the both of them using SQL Server 2012, but the OS is different. The older one is using Windows Server 2008R2 Standard, while the newer one is Windows Server 2012R2 Standard, both of them is x64. The other difference is the exact version number of the SQL Server, so the older is
Microsoft SQL Server Management Studio 11.0.3128.0
Microsoft Data Access Components (MDAC) 6.1.7601.17514
Operating System 6.1.7601
while the newer:
Microsoft SQL Server Management Studio 11.0.5343.0
Microsoft Data Access Components (MDAC) 6.3.9600.17415
Operating System 6.3.9600
I already created a properly working linked server to get data from our DB2/AS400 database on the old server. I used Data Access Tool 4.0 to make a connection string and got the following one:
Provider=DB2OLEDB;User ID=****;Initial Catalog=CAT;Network Transport Library=TCPIP;Host CCSID=37;PC Code Page=1252;Network Address=****;Network Port=446;Package Collection=DATA;Default Schema=DATA;Process Binary as Character=True;Units of Work=RUW;Default Qualifier=DATA;DBMS Platform=DB2/AS400;Use Early Metadata=False;Defer Prepare=False;DateTime As Char=False;Rowset Cache Size=0;Binary CodePage=0;Datetime As Date=False;AutoCommit=True;Database Name=TEST_DB;Authentication=Server;Decimal As Numeric=False;Derive Parameters=False;LoadBalancing=False;Persist Security Info=False;Cache Authentication=False;Connection Pooling=False;
Nowadays I would like to make the same linked server on the new one, but it couldn't convert the binary data as a proper one.
For example data from old server compared to the new one:
"" === 0x404040
M === 0xD4
Connection string that used on the new server:
Provider=DB2OLEDB;User ID=****;Initial Catalog=CAT;Network Transport Library=TCPIP;Host CCSID=37;PC Code Page=1252;Network Address=****;Network Port=446;Package Collection=DATA;Default Schema=DATA;Process Binary as Character=True;Units of Work=RUW;Default Qualifier=DATA;DBMS Platform=DB2/AS400;Use Early Metadata=False;Defer Prepare=False;DateTime As Char=False;Rowset Cache Size=0;Binary CodePage=0;Datetime As Date=False;AutoCommit=True;Database Name=TEST_DB;Authentication=Server;Decimal As Numeric=False;Derive Parameters=False;LoadBalancing=False;Persist Security Info=False;Cache Authentication=False;Connection Pooling=False;
I already tried:
Used Data Access Tool 4.0 because it already worked in the past (Process Binary as Character = True)
Used Data Access Tool 5.0 to be more compatible with SQL Server 2012 (Process Binary option is not included)
Installed hotfix from the MS Support (https://support.microsoft.com/en-us/kb/2993741)
Went through the possible settings and tried some combinations
Compared the already working linked server and the newly created one
Please help me how can I solve this problem!
Installed the i series ODBC driver on to the system and configured a system DSN, which should connect to the database.
https://social.msdn.microsoft.com/Forums/en-US/eae2d05f-32e8-4541-87fb-70fc12697d15/ms-ole-db-provider-for-db2-v5?forum=sqldataaccess
I am trying to copy data from Oracle to SQL Server 2012, and I get the following message when selecting Data Source as Microsoft OLE DB Provider for Oracle:
Test connection failed because of an error in initializing provider.
Oracle client and network components were not found. These components
are supplied by Oracle Corporation and are part of the Oracle Version
7.3.3 or later client software installation.
I tried using .NET Framework Data Provider for Oracle and I get:
Attempt to load Oracle client libraries threw BadImageFormatException.
This problem will occur when running in 64 bit mode with the 32 bit
Oracle client components installed (system.data.oracleclient).
In SQL Server 2000 (which I am trying to move to SQL Server 2012/2014), I have the option of selection Oracle in OraClienthome directly.
Some additional information that may help diagnose the problem:
Using Toad 64 bit, it points to the 64 bit Oracle download; however, I can not tell if it is using a 32 bit driver or 64 bit driver. I can also run queries, etc. without issue.
ODBC, I can see Oracle when making a 32 (I am guessing) bit ODBC connection named Oracle in OraClienthome, but not in SysWOW64 odbc connection.
I successfully established a linked server connection on a server running 64 Bit SQL Server 2012. OraOLEDB.oracle shows up under Server Objects Linked_Server Providers
While creating an SSIS package, I am unable to establish a connection to Oracle.
I can successfully run queries in MS Access and Excel.
(NEW) I can copy files using Import Export Data 64 bit, but not 32 Bit.
Any help would be greatly appreciated!
In many cases the 64 bit drivers are not compatible and you have to install the 32 bit drivers then be sure you are selecting to use the 32 bit drivers if you create a job to run the package which is in the command options as the last check box. I also use toad to pull data from oracle on my desktop and it works fine with the 64 bit driver but on our new server I had to install the 32 bit drivers even though I was able to create odbc connection with connection manager. Also had to reboot win server after instal before I could get it to take.
Try to install and use Oracle Client on the MS site, and transfer the data using SSIS.
I got same problems, but when i've used connection using oracle client (you will see it in connection selection options) all worked ok.
Good luck!
I need to create Link Server in SQL Server 2012 Enterprise 64 using Oracle ODAC.
I have done everything I know, including multiple re-installation of Windows Server 2012 Standard R2 64. The ODAC is also 64bit.
I am able to connect to Oracle 11g using Oracle SQL Developer using TNS as Connection Type.
I am beginning to think this may have something to do with Windows Server. Because I have never experience this issue on other systems not running Windows Server.
I get this error:
returned message "ORA-12154: TNS:could not resolve the connect identifier specified.
Thanks
After combining through hundreds of internet posts and install/reinstall. I discovered the problem was the ORACLE ODAC Components. Every article on the internet tells you to install 64bit ODAC if you are running 64bit database, however, this is not accurate.
After spending two days trying to get this to work, I decided to try the 32bit ODAC and it worked.
In case anyone is having this same issue.