There is a param on ODBC connection strings called Driver.
My old application always used {SQL Driver} and I know there is {SQL Native Client} and others.
My questions are:
What is the difference between these types of Drivers?
When do I should use one or another?
I'm not defining a Provider on my connection. Should I?
What is the best way to configure my connection string?
I'm using SQL Server 2005 Standard
Related
I want to use Always Encrypted feature introduce in SQL Server 2016 SP1. In order to do that, I need to use the new ODBC Driver 13.1 for SQL Server instead the current one sqloledb.
It seems it is breaking my application, for example, when XML is returned. Here, it is said that:
In order to take advantage of new features introduced in SQL Server
2005 such as multiple active result sets (MARS), query notifications,
user-defined types (UDTs), or the new xml data type, existing
applications that use ActiveX Data Objects (ADO) should use the SQL
Server Native Client OLE DB provider as their data access provider.
So, that's this mean that I need to rewrite code, where XML is used?
I know that, Microsoft undeprecated the deprecated sqloledb driver, but its first version coming in March 2018 will not support Always Encrypted - so, I do not want to wait.
Classic ADO has no notion of the SQL Server XML type. The legacy SQLOLEDB provider and legacy SQL Server ODBC driver return type adLongVarWChar (203) for XML so it's a string on the client side.
The newer SQL Server Native Client OLE DB provider returns type 141 for XML to ADO but there's no matching ADO DataTypeEnum (https://learn.microsoft.com/en-us/sql/ado/reference/ado-api/datatypeenum). The provider will return XML data as adLongVarWChar when the DataTypeCompatibility=80 connection string keyword is specified for ADO compatibility.
Unfortunately, there is no equivalent DataTypeCompatibility connection string keyword for ODBC drivers. The newer ODBC drivers return XML data as ADO type adLongVarBinary (205) when accessed via the MSDASQL provider classic ADO uses for ODBC drivers. So the XML will need to either be cast to/from nvarchar(MAX) in SQL queries or the adLongVarBinary value converted on the client side.
I can't say if the yet unreleased Microsoft OLE DB Driver for SQL Server will provide relief by supporting the DataTypeCompatibility keyword but I hope it does, similarly to Native Client. Hopefully, we'll know more details soon. I doubt ADO will be beefed up to support the newer SQL types natively since it's hardly been touched in the last 15 years but I've been wrong before.
I would not use the ODBC driver; it has a number of "wontfix" bugs.
Instead you should use the currently supported MSOLEDB driver: Microsoft OLE DB Driver for SQL Server
And you will have to include in your ConnectionString:
DataTypeCompatibility=80
for the reason's Dan said.
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...
This question is more about the "why". When you specify DRIVER={SQL Server Native Client 11.0} in a connection string, varchar(max) columns are returned blank. This issue seems to have carried on over the years, and some workarounds exist.
https://connect.microsoft.com/SQLServer/feedback/details/419996/sql-native-client-returning-blank-fields-to-excel
https://connect.microsoft.com/SQLServer/feedback/details/467300/problem-with-varchar-max-via-sql-native-client
While it seems crazy that these issues still exist, a valid workaround, suggested by:
https://stackoverflow.com/a/33883901/4258124
is to change the connection string to use:
DRIVER={SQL Server}...(rest of connection string)
instead of:
DRIVER={SQL Server Native Client 11.0} ...(rest of connection string)
I've tried this, and it works, but my question is more about "why". If DRIVER={SQL SERVER} is an older driver, how is it able to connect when I pass newer features like MultiSubnetFailover=Yes/True ?
I noticed I have installed (windows, from odbcad32.exe > Drivers) "ODBC Driver 11 for SQL Server" (MSODBCSQL11.DLL dated 2014) and "SQL Server" (SQLSRV32.DLL dated 2010).
In VBA or Python on Windows, does passing {SQL Server} pick the newer of the above two ? Would any features be lost in using {SQL Server} over {SQL Server Native Client 11.0}, and if so, what would they be ? Is there a better workaround ?
In VBA or Python on Windows, does passing {SQL Server} pick the newer of the above two ?
No. {SQL Server} is simply the name of the (very old) SQL Server driver that ships with Windows. It is still used in a lot of places, but it does not support the newer features of SQL Server and has probably been deprecated for a long time now.
In fact, the family of {SQL Server Native Client ...} drivers has had also been deprecated in favour of the {ODBC Driver __ for SQL Server} drivers (where __ is currently either 17, 13, or 11). However, as Microsoft is wont to do, it has changed its mind and "undeprecated" the OLE DB access method (previously "SQLNCLI11", now called "MSOLEDBSQL").
Would it be possible to connect to SQL server using DSN however using SqlClient rather than ODBC.
As a matter of fact we have to upgrade a legacy VB6 component however we have to keep the user suitability same ie the users are connecting to database using a DSN.
I would like to avoid ODBC if it would be possible to connect using SqlClient.
Any comments, examples would be appreciated.
ta
Basically the answer is no. Either use ODBC or OLEDB.
What is the difference between SQL Server Native Client connection and ODBC connection? What are the pros and cons of these two?
Huh? ODBC is officially dead? Someone might want to let Microsoft know that:
Microsoft is Aligning with ODBC for Native Relational Data Access
From the above link:
ODBC is the de-facto industry standard for native relational data access...
and
The commercial release of Microsoft SQL Server, codename 'Denali' will be the last release to support OLE DB.
and finally,
"We encourage you to adopt ODBC in the development of your new and future versions of your application. You don’t need to change your existing applications using OLE DB, as they will continue to be supported on Denali throughout its lifecycle. While this gives you a large window of opportunity for changing your applications before the deprecation goes into effect, you may want to consider migrating those applications to ODBC as a part of your future roadmap. Microsoft is fully committed to making this transition as smooth and easy as possible.""
(emphasis added)
ODBC is useful for times when the underlying database might change but you don't want your code to (assuming the SQL stays the same across technologies). You could connect to an Oracle database one day and switch out to a SQL server database the next. The disadvantage is that you don't get the optimizations that having specific drivers affords you. The SQL Server Native client driver has been proven to be much faster than just using a standard ODBC driver.
What is the difference between SQL Server Native Client connection and ODBC connection?
ODBC is a standardized API.
ODBC drivers are shared libraries that use native protocols (like SQL Server shared memory, or SQL Server TCP/IP) to implement the ODBC interface.
In other words, ODBC is an abstraction that enables code to work against multiple database technologies.
It's similar to Java's JDBC, or Python's DB-API, or GO's database/sql, except ODBC drivers use C functions. Also, they are more frequently installed at a system level.
ODBC has the usual pros and cons of any abstraction.
Pros: Makes code more flexible/portable.
Cons: Adds performance overhead and has fewer features.
It sounds like you know that you will use SQL Server and will always use SQL Server.
In that case, I'd use a native client library if it's available.
SQL Server Native Client is a single dynamic-link library (DLL) containing both the SQL OLE DB provider and SQL ODBC driver for Windows.
SNAC 11 is a single dynamic-link library (DLL) containing both the SQL
OLE DB provider and SQL ODBC driver for Windows. It contains run-time
support for applications using native-code APIs (ODBC, OLE DB and ADO)
to connect to Microsoft SQL Server 2005, 2008, 2008 R2, and SQL Server
2012. A separate SQL ODBC-only driver is available for Linux.
https://blogs.msdn.microsoft.com/sqlreleaseservices/snac-lifecycle-explained/