I'm setting up a replacement server. Mostly it runs Mathematica jobs. I set up the ODBC connections on the new box to be the same as on the old box, but when Mathematica tries to connect, using
testConn=OpenSQLConnection[JDBC["odbc","MyODBCName"]]
I get
JDBC::error: [Microsoft][ODBC Driver Manager] Invalid string or buffer length
Searching on this mostly finds other people with related problems. Some references to 32/64 bit Java issues. I have Java 1.6.0_24 (32 bit) on the new server, 1.6.0 on the old. And Wolfram has not responded yet. Some programs that don't use ODBC to connect work fine on the new box.
Software versions are Mathematica 7, MS SQLServer 2008 on both boxes, Windows Server 2008 on the new one and Server 2003 on the old one. I created ODBC connections using both the 32 and 64 bit versions of odbcad32.exe
What am I missing, what didn't I tell you and what do you suggest?
Thanks, **kent
Some people have had success by installing the Microsoft Access Database Engine 2010 Redistributable. Even though this update says "Access" in the title, it might be relevant to your problem because it also updates the ODBC framework itself.
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.
I'm trying to connect to an Oracle Database on our server from an Excel sheet, but am having trouble understanding why.
I currently have both 32-bit and 64-bit Oracle 12c installed in different ORACLE_HOMEs and have a 32-bit installation of Excel on my 64-bit computer.
I'm trying to connect to an Oracle Database in Excel using the New Query wizard.
When I click From Oracle Database I get the following error/message.
I can continue with my current provider, but when I actually try to connect to a database I get this:
What I don't understand is why I'm getting this error when I have both 32-bit and 64-bit versions of Oracle 12c installed on my computer. Both are included on my PATH variable (32-bit first), and I also included a specific ORACLE_HOME and TNS_ADMIN to point to my 32-bit installation since my excel is 32-bit.
I really want the ability to query from the database through Excel, but this problem is confusing me to death.
EDIT
I've also just added the ODBC Driver from my Oracle home's into the ODBC Data Source Administrator Tool.
It's currently able to connect from this tool.
But when I try to connect to going through the ODBC Connection wizard, I know get this:
Any Ideas?
How did you install 32bit and 64bit Oracle Client?
Please have a look at this instruction: BadImageFormatException. This will occur when running in 64 bit mode with the 32 bit Oracle client components installed
Short version:
Your excel is 32bit and you try to use the 32bit Oracle. I assume you launch the 64bit version of "ODBC Administrator" - there might be the mismatch. Or you have a problem in your PATH regarding %ORACLE_HOME% and/or %ORACLE_HOME%\bin folder
Long version:
Your Excel is 32bit, so in general you did the right approach by putting the 32bit Client into PATH and for ORACLE_HOME, you cannot mix 32bit and 64bit assemblies in one process. Btw, when you follow the instructions above your Windows will manage this automatically.
I assume you installed the Oracle Instant Client. The default Instant Client does not include neither any ODBC driver nor Oracle Data Provider (ODP.NET, Oracle.DataAccess.Client)
ODBC
You may have 2 ODBC drivers, one from Oracle typically called like Oracle in OraClient12_home1 and one from Microsoft called Microsoft ODBC for Oracle (which should be installed by default Windows installation, however it also requires an Oracle Client).
The ODBC driver from Oracle is available for 32bit and 64bit, the Microsoft driver exits only for 32bit. You have 2 ODBC Administrators, 32bit (run c:\Windows\SysWOW64\odbcad32.exe) and 64bit (run c:\Windows\System32\odbcad32.exe). There you should see installed drivers for 32 resp. 64bit.
Oracle Data Provider
For the Data Provider you have similar situation. You have one from Microsoft (Microsoft .NET Framework Data Provider for Oracle, System.Data.OracleClient) and from Oracle (Oracle Data Provider for .NET, Oracle.DataAccess.Client, several versions). Both are available for 32bit and 64bit.
In principle it does not matter which driver/provider you use to connect to Oracle - just the architecture (i.e. 32 vs. 64 bit) has to match. Each driver/provider requires according Oracle Client installation. All drivers/providers from Microsoft have been deprecated, you should prefer the Oracle ones (as stated in the warning message)
Others
Oracle provides also the ODP.NET, Managed Driver which does not require any further Oracle Client installation and runs on both, 32bit and 64bit. However, I don't know whether you can use this in Excel.
Last but not least, you also have OLE DB provider. Again one from Microsoft (Microsoft OLE DB Provider for Oracle) and one from Oracle (Oracle Provider for OLE DB). The Microsoft provider exist only for 32bit and has been deprecated.
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...
I have a strange (but also common) problem with Crystal Reports.
DB is SQL Server 2014 Express (12.0.2000 or 12.0.2269)
Web app can connect to DB with no problems. Problem arises when user wants to run a report.
Now, I have few production sites. A Windows Server 2012 R2 cloud VM, couple of Windows Server 2008 R2 machines and one Windows 10 machine.
Reports run fine on windows server 2008 machines, but not on server 2012 R2 or win 10. There, I get dreaded database logon failed error. It even doesn't work on my development laptop (Win 10). I mean I can run reports from within Visual Studio, but not after I deploy them to IIS.
Reports themselves mostly use sql native client (SQLNCLI11) driver for connecting to db, some of them are using OLE DB (SQLOLEDB), but that doesn't seem to be the problem since I've tried both versions, and they both fail.
Now, I would think maybe there is some dll missing in my app, but that very same app deployed to win server 2008 works just fine. So I am thinking, it must be environmental. But what?
I am guessing that client drivers are somehow broken, or something is changed in newer versions of windows.
So, I am asking for some ideas, to point me in right direction, if somebody has any.
Here is error snippet:
[COMException (0x8004100f): Database logon failed.]
CrystalDecisions.ReportAppServer.Controllers.ReportSourceClass.Export(ExportOptions pExportOptions, RequestContext pRequestContext) +0
CrystalDecisions.ReportSource.EromReportSourceBase.ExportToStream(ExportRequestContext reqContext) +644
[LogOnException: Database logon failed.]
CrystalDecisions.ReportAppServer.ConvertDotNetToErom.ThrowDotNetException(Exception e) +263
CrystalDecisions.ReportSource.EromReportSourceBase.ExportToStream(ExportRequestContext reqContext) +1522
CrystalDecisions.CrystalReports.Engine.FormatEngine.ExportToStream(ExportRequestContext reqContext) +704
CrystalDecisions.CrystalReports.Engine.ReportDocument.ExportToStream(ExportOptions options) +115
CrystalDecisions.CrystalReports.Engine.ReportDocument.ExportToStream(ExportFormatType formatType) +96
SYSTEM.Controllers.ReportController.GenerateReport(NameValueCollection Form, String how) in C:\SYSTEM\SYSTEM\Controllers\ReportController.cs:210
SYSTEM.Controllers.ReportController.Index() in C:\SYSTEM\SYSTEM\Controllers\ReportController.cs:467
lambda_method(Closure , ControllerBase , Object[] ) +90
UPDATE:
It seems to be due to Windows 10, but I haven't found a solution.
SAP says install .NET 3.5, because it's not installed by default in WIN 10, but even when I do, error persists.
You should install 13.0.15 version of CR, because it't the only one that supports WIN 10, but as I said, it doesn't work.
I've tested on three different WIN 10 machines, always the same result.
I've run into issues when using a OLE DB (ADO) data source type, along with a Native Client provider. When that Native Client isn't installed on the consuming user's computer, it asks for a database login, and it seems that no login will work. My solution was to use the OLE DB (ADO) data source with the OLEDB provider as well. You can see the provider by looking at the properties of the data source by right-clicking on it. The preferred provider in this case is SQLOLEDB, whereas the Native Client will be something like SQLNCLI11.
You must utilize SQL-Client 2005 or version 10 (I guess).
Crystal Reports is really problematic if using the most recent drivers.
Try to establish the connection using the client-driver of SQL 2005 - it will function...
If anyone is interested, let my just share the solution:
It wasn't crystal reports, nor Windows 10, it was me. My reports were built upon SQL Server 2008, which uses SQLNCL10, and SQLNCL11 is not backwards compatible with it, hence database logon error (which is not helpful at all, btw).
Just in case.