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/
Related
i want add a new linked server in my SQL Server (14.3026.27) Linux Red Hat Enterprise 7.5, before i add a linked server to other SQL Database, but now when i want add a linked server to MySQL i cant.
I check my SQl Server linux and i found that i not had any provider in the section "Server Objects" i need MSASQL for do it i think.
My Question is How addproviders in SQL Server Linux? or can´t add linked servers to MySQL in my current server?
Any other information is very apreciate, thanks.
You can't. To quote from Unsupported features & services:
The following features and services are not available on Linux at the
time of the GA release. The support of these features will be
increasingly enabled over time.
Database Engine:
Merge replication
Change Data Capture (see SQL Server Agent)
Stretch DB
PolyBase
Distributed query with 3rd-party connections
Linked Servers to data sources other than SQL Server
System extended stored procedures (XP_CMDSHELL, etc.)
Filetable, FILESTREAM
CLR assemblies with the EXTERNAL_ACCESS or UNSAFE permission set
Buffer Pool Extension
Emphasis mine.
This isn't supported at the time of writing.
The list of unsupported features includes
Linked Servers to data sources other than SQL Server
It also says
The support of these features will be increasingly enabled over time.
If you have any relationship with Microsoft you may be able to speak to them in more detail about if/when they will enable the feature you want.
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 have an SQL Server database, and I need to push data into it through vbscript, as well as pull data into Excel. I have found multiple connection strings, but no repository for the benefits of performance and functionality comparing them. The driver options (Provider=) I have found so far are:
{SQL Server} (ODBC)
SQLOLEDB (newer than ODBC, but being deprecated?)
SQLOLEDB.1 (what Excel 2016 uses when clicking 'Get External Data', but not even mentioned on connectionstrings.com... I assume a newer version of the above, but still the deprecated technology?)
SQLNCLI11 (native client, OLE DB)
{SQL Server Native Client 11.0} (native client, ODBC)
Different things I read say that ODBC is better because it has been around longer. And that OLE DB has been around long enough to have the same advantages. And OLE DB was made to work with a certain company's applications. And ODBC was made by the same company. And OLE DB can connect to and from different kinds of applications better. And ODBC works better with databases. And Native is...Native, so must be better... because of the name?
I find multiple questions here on SO floating around with no or partial answers, or having multiple comments claiming the answers are out of date. So, as of now, what the specific differences between these different drivers? Do they have different performance in different circumstances? Do they have different features? Do I need to do profiling to determine the best performance and reliability for my particular use case, or is there a standard "best practice" recommended by Microsoft or some recognized expert? Or are they all basically doing the same thing and as long as it's installed on the target system it doesn't really matter?
ODBC-it is designed for connecting to relational databases.
However, OLE DB can access relational databases as well as nonrelational databases.
There is data in your mail servers, directory services, spreadsheets, and text files. OLE DB allows SQL Server to link to these nonrelational database systems. For instance, if you want to query, through SQL Server, the Active Directory on the domain controller, you couldn't do this with ODBC, because it's not a relational database. However, you could use an OLE DB provider to accomplish that.
http://www.sqlservercentral.com/Forums/Topic537592-338-1.aspx
Does using the ADO.NET Provider that a DB vendor wrote eliminate the need to have any database drivers installed on the machine?
I'm a bit confused on how ADO.NET actually works.
An ADO.Net provider is a database driver.
However, ADO.Net providers are (hopefully) purely managed, so they don't need any installation.
It depends on how they wrote the provider. The provider can be written to include any driver, but it could also be written to expect to talk to a driver that is installed on the machine separately.
For example, Microsoft's own Sql Server provider still expects you to have the "native client" installed on each machine. But system.data.sqlite includes all that as part of the provider for the sqlite database.
There are Ado.NET providers specific to database which are tailored versions of DB drivers.
Eg: SQLClient -tailored version for SQL server family
iAnywhere -tailored version for Sybase db.
And we have ODBC drivers in Ado.NET which is not specific rather generic driver available out of the box.
I understand that some databases have native support in R (e.g. MySQL) but you can connect to other DBs like MS SQL Server using RODBC. How much speed improvement does one gain for reading/writing with the native drivers vs. RODBC? What other DBs have native drivers in R? Is reading faster or slower than writing generally?
If you're specifically interested in SQL Server, the reference below is a little bit out of date but I imagine it probably still holds.
Using ODBC with Microsoft SQL Server
Performance of ODBC as a Native API
One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API. This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. This translation effort adds extra processing compared with having the application call directly to the native API. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way.
The Microsoft SQL Server ODBC driver is a functional replacement of DB-Library. The SQL Server ODBC driver works with the underlying Net-Libraries in exactly the same manner as the DB-Library DLL. The Microsoft SQL Server ODBC driver has no dependence on the DB-Library DLL, and the driver will function correctly if DB-Library is not even present on the client.
Microsoft's testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.
It's an empirical question, so why don't measure it for the combination you are interested in?
Public code is not hidden, so why don't you count what other DB interfaces CRAN has? For DBI alone, we have SQLite, MySQL, Postgresql, Oracle; for custom db backends there are things like Vhayu.
Specialised forums exist, so why don't you ask on r-sig-db?
Lastly, as soon as there is an API and a need people tend to combine the two. I have written two different (at-work and hence unreleased) packages to two highly specialised and fast backends.