I am investigating the possibilities to connect to a MSSQL database from a RHEL6 application server. I have found two ways:
FreeTDS
Microsoft SQL Server ODBC Driver for Linux + unixODBC
Does anyone have experience in using either of these setups? (I'm especially curious about the latter, since it is officially supported by MS). Performance? Stability? Any other options I might be missing?
For the record, I went with FreeTDS at the moment. I evaluated both unixODBC and FreeTDS and found FreeTDS easier to work with at the moment.
Another option is the MS JDBC driver for SQL Server
If you're working with older versions of SQL Server (e.g. 2000), current Microsoft ODBC drivers may not work.
FreeTDS claims to work with all versions of MS SQL Server:
http://www.freetds.org/faq.html#Does.FreeTDS.support.my.server
Related
I am a Database Developer and currently working in SQL Server Technology. I am trying to find out the ODBC driver name based on the installed SQL Server Version. Here is what I mean - Example,
We are using SQLCMD.exe to execute some scripts through our custom MSI. SQLCMD fails if it doesn't find the correct ODBC driver. Hence we need to be able to identify the correct ODBC version based on the SQL version installed, so that we can check this before installation and prompt the user to install the correct ODBC version as a prerequisite.
I have already explored the below -
Windows Registry - I did not get a clear cut idea of how to identify ODBC drivers based on versions. ODBC drivers and SQL Server versions are mentioned at multiple places and either they do not match amongst themselves or with the installed SQL Server Version.
Admistrative Tools -> ODBC Admistrator -> Drivers Tab
SQL Server Version here do give some idea but we are unable to decode odbcad32.exe. Link - https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/check-the-odbc-sql-server-driver-version-windows?view=sql-server-2017
If anyone knows anything then please render help. We need a solution using C# ( recommended ), however, if any other technology then we can have a look for its feasibility.
Thanks in advance.
Windows registry is the best way to go, I'm not sure why you're seeing inconsistencies. There are two main places to look:
For 64bit: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\ODBC Drivers
For 32bit: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC\ODBCINST.INI\ODBC Drivers
If you want the specific version, you will need to go up a level into the registry keys that have the same name as those listed in ODBC Drivers. For exmaple, under ODBC Drivers you have the key "ODBC Driver 17 for SQL Server" listed as installed, under ODBCINST.INI you will have a entry called "ODBC Driver 17 for SQL Server" where you can find further details.
ODBC driver versions aren't intrinsically linked to the version of SQL installed. It's absolutely possible the ODBC driver has been updated separately, and/or multiple versions are installed.
Where can I find the information with which SQL Server versions the standard ODBC driver named "SQL Server" (SQLSRV32.dll) is compatible ?
For sure it works with Microsoft SQL Server 2008 R2 because we are using them successfully.
But what about the following?
Microsoft SQL Server 2012
Microsoft SQL Server 2014
Microsoft SQL Server 2016
Microsoft SQL Server 2017
Unfortunately I could not find that information after hours using my favourite web search engine.
On https://learn.microsoft.com/en-us/sql/connect/odbc/windows/microsoft-odbc-driver-for-sql-server-on-windows
are descriptions of newer drivers which can be downloaded, but we don't have admin privileges to install one of them.
We have to use the standard ODBC driver which is installed on Windows out of the box, because the application should run on customers desktop PCs.
Probably this information also depends on the version of the DLL. As an example let's take the version 10.00.15063.00, but it can vary, for the reason mentioned above.
We do not exactly know which Windows versions the customers use. Can be [Win7, Win8, Win10] / [Home/Pro/Enterprise].
The "SQL Server" ODBC driver that ships with Windows is part of Microsoft/Windows Data Access Components (MDAC/WDAC) and is an operating system component nowadays. The specific driver version number shouldn't be a concern given that the interface is the same. This ODBC driver is legacy and has not been enhanced for many years. It is included with Windows only to support legacy applications and is unaware the new SQL data types and features introduced since the release of SQL 2005. It is not intended to be used for new development but nothing prevents you from using so.
Most Java applications use a JDBC driver for relational database access. You could use a modern JDBC driver and include it with your application. That will allow you to use newer SQL features.
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...
Office for Mac 2011 has better support for Pivot Tables in Excel, including external data.
I need an ODBC connection on a Mac to SQL Server 2008. Microsoft recommends using a JDBC driver, but the documentation for it is very, very, very weak.
Here is the link to the JDBC driver: http://msdn.microsoft.com/en-us/sqlserver/aa937724
Now, once that is downloaded and extracted, you can add the JDBC driver via the Apple ODBC Administrator.
.
Finally, you can add the ODBC connection, but it won't let me edit the keyword or values.
:
A few questions:
Am I using the right driver/do I have it installed correctly?
Is there a way to change the keyword values in the ODBC Administrator?
Thanks
Just to help those who stumble across this problem:
Control + Click to edit both Keyword and Value fields in Mac OS X ODBC Administrator.
Alternatively, Command + Return
Tab-bing through the fields work as well.
I'm not sure where you found the recommendation to use a JDBC driver with MS Office 2011. I am sure it won't work out.
However -- ODBC drivers for Mac do exist, for MS SQL Server and other DBMS, and these are fully compatible with MS Office 2011. My employer makes a number of these drivers.
For your specific need, I'd start here.
Good luck!
Edited to clarify: All versions of Microsoft Office are built with ODBC client capabilities. None have JDBC client capabilities. If you're to use Microsoft Office against an JDBC driver, you'll also need an ODBC Driver for JDBC Data Sources ... such as this one from my employer.
I found out about the freeTDS which can be used here, but there are doubts about its stability in the production environment. Is there any other way to interactive with MSSQL Server from Solaris besides using ODBC driver?
Don't know of any other way.
We're using unixODBC + freeTDS + DBD::Sybase in a production environment.
It can be fiddly setting it up, but we have no problems with stability.
It is possible to use FreeTDS directly and bypass unixODBC.