Connecting to SQL 2017 with SQL Server Driver from Windows 2012R2
-
Hi
we have a legacy application that connects from the application servers (Windows 2012 R2) to the SQL servers using the SQL Server driver.
This work fine against an old version of SQL, but we're upgrading to SQL 2017, and it no longer connects.
You can connect from Windows 10 using the SQL server driver. The driver on Windows 10 is version 10.xxxx and on 2012R2 its 6.xxxxx
Windows 2012
Windows 10
For various reasons we don't want to change the code to use an update SQL ODBC driver, or upgrade the OS on the application server. Does anyone know if there is a way to upgrade the SQL Server driver on the 2012R2 application boxes, to make it compatible with SQL 2017
-
My first thought - what error are you getting in the application and in your logs (SQL and Windows)?
My guess, without seeing your system and setup, is that it is more likely to be a firewall related issue than a driver issue, but it depends on what the error message is and how you did the upgrade. If it was an in-place upgrade, then it likely isn't the firewall, but is still something I'd check. If it was a migration install, I would be looking hard at the firewall (software and hardware).
BUT, If you are using encrypted connections, I could see that being an issue in the driver and the only fix being to update your driver.
One thing you could do in your code (note I have not tested this, but don't see why it wouldn't work, and I have used it for other libraries) would be to change your reference to SQL Server to "copy local". Then your application should use the version of that DLL in the local folder rather than in system32 or syswow64 (depending on if you are using the 32-bit driver or the 64 bit driver). This change results in a recompile to pull all of the files into your bin folder, but should require no code changes (just a configuration change).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Thanks for the reply Brian
It's definitely a driver issue.
If I create a DSN from the application box using the SQL server driver and test it I get
Microsoft SQL Server ODBC Driver Version 06.03.9600
Running connectivity tests...
Attempting connection
[Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error
TESTS FAILED!Using the SQL ODBC 13 driver from the same box I get
Microsoft ODBC Driver for SQL Server Version 13.00.4414
Running connectivity tests...
Attempting connection
Connection established
Verifying option settings
Disconnecting from server
TESTS COMPLETED SUCCESSFULLY!Again we're trying to avoid any sort of code update because it could be referenced in hundreds of separate bits of code
-
That error "SSL Security Error" is the problem for sure. Best guess - the old driver is using a weaker encryption method than the new one so SQL is refusing the connection... or could be an ODBC configuration issue. Again, I can't see your system, so I am just guessing here.
As for updating the driver, this link MAY work for you - https://docs.microsoft.com/en-us/sql/connect/odbc/download-odbc-driver-for-sql-server?view=sql-server-ver15
Although it may cause problems too. I would try that out on a test system and see if it works before deploying to live. I am also not sure if the latest ODBC driver works with windows 2012R2 as that version is out of support.
On top of that, if any of your pieces of code have the reference set to "copy local" (or have the DLL embedded, but I don't know that the SQL driver supports embedding) and are using the old driver, updating the driver on the server won't make a difference.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply