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.
Related
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...
Our client recently upgraded from TLS 1.0 to TLS 1.2 and after this our software cannot connect with SQL server. It uses OLE DB provider for connecting to SQL server.
Below is the error which is returned from SQL server-
[DBNETLIB][ConnectionOpen SECDoClientHandshake()]SSL Security error
SQL State: 08001
SQL Error Number: 18
Could not find any useful information related to whether Microsoft OLE DB Provider for SQL Server support TLS 1.2 or not.
One of the links I found seems to suggest that it is not supported.
https://forums.iis.net/t/1233674.aspx?connecing+SQL+server+DB+issue+after+installingTLS1+2+in+SQL+srver+with+classic+asp+application+
Hence, wanted to check on stackoverflow in case anyone has any information on this.
The SQLOLEDB provider and the SQL Server ODBC driver that ship with Windows are legacy components provided only for backwards compatibility. These have been deprecated since SQL 2005.
According to this blog post by the MSSQL Tiger Team:
SQLOLEDB will not receive support for TLS 1.2. You will need to switch
your driver to one of the supported drivers listed in
https://support.microsoft.com/en-us/kb/3135244
You should be able to install SQL Server Native Client 2012 and use that OLE DB provider with only a connection string change (change Provider=SQLOLEDB to Provider=SQLNCLI11). Of course, once should test to avoid surprises. For example, I recall someone experiencing behavior differences with the SQL Server Native Client provider and ADO classic when server API cursors were used, although the commonly used firehose cursors were fine.
EDIT
The new OLE DB driver, MSOLEDBSQL, has been released. This new driver includes the support for the latest TLS 1.2 standards and is backwards compatible with SQL Server Native Client 11 (SQLNCLI11). See the Microsoft SQLNCLi team blog announcement. Change the connection string to Provider=MSOLEDBSQL after installation.
EDIT #2
Time continues to march on. The SQL Server Native Client OLE DB driver is now deprecated in favor of MSOLEDBSQL. End of support for the final 2012 SNAC version is July 12, 2012.
Furthermore, as David called out in his answer, Microsoft recently added support for TLS 1.2 MDAC components in Windows 10 Build 17763.1554:
Adds support for the Transport Layer Security (TLS) 1.1 and 1.2
protocols when connecting to SQL Server using the data providers in
Microsoft Data Access Components (MDAC)
No enhancements (e.g. support for post-SQL 2000 data types) were added, though.
In summary, newer SQL Server client drivers provides more control over the specific driver and version without a direct OS patch level dependency. Modern drivers like MSOLEDBSQL and ODBC Driver n for SQL Server are continuously improved to support latest SQL Server features and security standards.
EDIT#3
SQLOLEDB and the SQL Server ODBC driver (part of MDAC, shipped and serviced with Windows) has support for TLS 1.2 with October 20, 2020 build, version 17763.1554. This applies to Windows 10 and Windows Server 2019 or later.
This may not be a solution for you, since it's a future fix your client may not be able to wait for, but apparently Microsoft is undeprecating the OLEDB Driver, with a new release supporting TLS 1.2 out Q1 2018: https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/
The new Microsoft OLE DB Driver for SQL Server, or msoledbsql, will
also introduce multi-subnet failover capabilities in this first
upcoming release, and keeps up with latest TLS 1.2 standards.
Also, this first upcoming release will be a stand-alone install
package that is out-of-band with SQL Server lifecycle. This also means
the driver will not be packaged in the SNAC library, nor coupled with
any other driver.
TLS 1.2 Support has been added to sqloledb in Windows. See KB4580390.
This includes support both ODBC and OleDB providers in MDAC:
Adds support for the Transport Layer Security (TLS) 1.1 and 1.2
protocols when connecting to SQL Server using the data providers in
Microsoft Data Access Components (MDAC)
You can verify that MDAC has been updated by checking the Windows build number, anything 17763.1554 or later has this fix. MDAC has not been distributed outside of OS patches for many years.
The build is visible in winver or in Powershell with [environment]::OSVersion.Version.Build
Following changes on my end fixed the issue after TLS1.2 upgrade on Azure cloud -
change Provider=SQLOLEDB to Provider=SQLNCLI11
update ADODB version to Microsoft ActiveX Data Objects 6.0 Library
The use of "Microsoft OLEDB Driver for SQL Server" is what worked for us but I can also confirm Native Driver 11 also tests OK.
Here was our scenario: after we disabled TLS 1.0 and 1.1 and enabled TLS 1.2, Crystal Reports using the "Microsoft OLEDB Provider for SQL Server" would no longer connect. Instead you get a user/pw prompt that fails with even with valid credentials. In our case we were running Crystal Reports from within an ASP.NET v4.5.2 application that has the Crystal 13 Viewer embedded in. Users pick from a list of reports and run them and they run without a prompt with TLS 1.0 enabled.
To fix this, we had to open the report in the designer and convert it report from using the "Microsoft OLEDB Provider for SQL Server" to using the "Microsoft OLEDB Driver for SQL Server".
If you don't see the driver in your list here's the OLEDB Driver for SQL Server: https://learn.microsoft.com/en-us/sql/connect/oledb/download-oledb-driver-for-sql-server?view=sql-server-ver15
Credit to Dan Guzman who mentioned the existence of the "driver" in a somewhat buried comment and an update above.
This might not directly answer the question, but it is still related to sql server connection with TLS 1.2 error.
I'm maintaining an old ASP Classic website which broke with following error.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.
Changing Provider from SQLOLEDB to SQL Server Native Client 11.0 or any higher version which is available fixed the error.
Thus, changing connection string from
constr = "Provider=SQLOLEDB;Data Source=..."
to
constr = "Provider=SQL Server Native Client 11.0;Data Source=...."
might work too
I have a project where the choice of database engine is still up in the air, based on affordability and feature-set. Some basic groundwork has been carried out using SQL Server, and in evaluating the cost implications of opting to adopt SQL Server, versus a different vendor's product, I noticed that Microsoft has just released their public preview of SQL Server v.Next, which allows one to run SQL Server on a Linux platform.
According to www.theregister.co.uk, the public preview is a SQL Server executable that runs on *nix-based systems by utilising Drawbridge, which is essentially a way of running Windows applications on a tiny version of the Windows 8 kernel, run inside a sandbox.
One issue most open source advocates have had with Microsoft's SQL Server is that SQL Server Enterprise contains all functionality, and when opting for a more budget-friendly version, certain limitations are imposed on you.
Specifically, Standard Edition and Web Edition impose upper limits on in-memory column store (32GB and 16GB respectively), and Web Edition removes backup compression as a feature.
I've searched the web in an attempt to find out how Microsoft intends to license SQL Server as far as Linux versions are concerned, my main concern being related to database mirroring. As far as database mirroring is concerned, SQL Server Standard and SQL Server Web Editions both have a subset of the functionality provided by SQL Server Enterprise.
I'm looking to understand three things:
How is Microsoft going to license SQL Server vNext for Linux (specifically, the Ubuntu version)?
If vNext is a subset of the functionality of the Windows version of SQL Server, what functionality is omitted?
Is database mirroring functionality present in the Linux distros of SQL Server vNext?
I don't think licensing information has been released yet.
What we do know is SQL Server Next on Windows & Linux will run a single feature set. Here is a quote taken from MS at Connect().
Microsoft officials said SQL Server Next on Linux and SQL Server Next
on Windows are based on a single code base. "There are some features
that have platform specific characteristics. For example, file paths
in Linux are different than file paths in Windows," said a
spokesperson. But they are not two completely different products.
My take on this is: SQL Server 2018 (or whatever it ends up being called) will be the same on Linux and Windows. This lines up with the big news about SQL Server 2016 Service Pack 1. MS have announced all editions will be functionally the same, from LocalDb to Enterprise.
While the Linux version remains in preview it is hard be sure what the final product will look like. If this is choice you have to make soon you may well feel the Linux solution isn't, quite, ready for prime-time.
In his excellent and popular comparision chart, ErikEJ draws a distinction between SQL Server Express 2012, and SQL Server 2012 LocalDB. However, I can't find such a distinction anywhere else in the MSDN documentation ("LocalDB" isn't even mentioned in the official MS SS12 book or on the MSDN SQL Edition comparison page.) This leads me to suspect that Express and LocalDB aren't really two separate products as ErikEJ suggests, but rather just two different terms for the same thing (which would explain why, on this MSDN page, it is called "SQL Server 2012 Express LocalDB").
If there really is a difference between the products, can anyone point me to some official documentation comparing them?
OK, I think I have found the answer to my own question. (It was buried under the tabs on the SS Express product page.)
Here is a summary of the distinctives of LocalDB I found on that page:
LocalDB is a lightweight deployment option for SQL Server Express Edition with fewer prerequisites and quicker installation.
LocalDB has all of the same programmability features as SQL Express, but runs in "user mode"* with applications and not as a service.
LocalDB is not intended for multi-user scenarios or to be used as a server. (If you need to accept remote connections or administer remotely, you need SQL Server Express.)
"Express with Tools" (which includes SS Management Studio Express, Azure, etc) can be used with LocalDB or without. (The same goes for "Express with Advanced Services".)
UPDATE: I just found this useful description in Windows IT Pro (Jul '12, p.23):
LocalDB isn’t SQL Server Express, nor is it SQL Server Compact.
LocalDB uses the same sqlservr.exe engine as the other editions of
SQL Server, but it runs in user mode—not as a service. LocalDB is
used for offline development by tools such as SSDT to ensure that the
code you develop is 100-percent compatible with your production
SQL Server database.
If I am reading this correctly, LocalDB seems to be more like a configuration option of Express than an entirely separate product. So apparently if I download Express (or Express w/ Tools), I will have the option to install the LocalDB version, which is supposedly easier ("zero-configuration") than the full Express. (Update: with VS2012, LocalDB comes installed by default.)
One other important distinction, according to this post, is that "currently Visual Studio 2010 doesn't really work with LocalDB." (We have to use SS Management Studio instead, at least for now.)
*(The concept of "User Mode" or "User Instances" is a key distinctive of LocalDB. In fact, according to this post, "LocalDB can be seen as an upgrade of the User Instances feature of SQL Server Express." For more about User Instances, refer to the MSDN blogpost "What is a RANU?")
UPDATE - Feb 2021
LocalDB is SQL Server Express edition
From official documentation
Express edition is the entry-level, free database and is ideal for
learning and building desktop and small server data-driven
applications. It is the best choice for independent software vendors,
developers, and hobbyists building client applications. If you need
more advanced database features, SQL Server Express can be seamlessly
upgraded to other higher end versions of SQL Server. SQL Server
Express LocalDB is a lightweight version of Express that has all of
its programmability features, runs in user mode and has a fast,
zero-configuration installation and a short list of prerequisites.
The docs provides a very detailed comparison of features between editions.
I use a table from ErikEJ, which shows: the features and differences between SQL CE 3.5, SQL CE 4, Local DB and SQL Server 2012. According to this table the differences between Local DB and SQL Server 2012 are:
Installation size:
SQL Server 2012: 120 MB download size; 300 MB expanded on disk
Local DB: 32 MB download size; 160 MB on disk
Runs as Service
SQL Server 2012: Yes
Local DB: No (runs as process started by app)
FILESTREAM support
SQL Server 2012: Yes
Local DB: No
Subscriber for merge replication
SQL Server 2012: Yes
Local DB: No
Number of concurrent connections
SQL Server 2012: Unlimited
Local DB: Unlimited (but only local)
NB: Sorry this isn't "official documentation", but hope it's useful to the next bod as it answers the underlying query about the differences.
The major difference are Server Express run as a service while LocalDB doesn't need any server or intensive processing to run.
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.