ODBC 17 for SQL server not able to connect (1 Viewer)

[nector]

Hi All

We have a challenge on ODBC for one machine its failing to connect to the database while others are connected see picture . Any solution? the internet is just okay.

 

[cheekybuddha]

Check the versions of access on the different machines.

There was a recent update that broke odbc (apparently now fixed)

 

[nector]

Then which version is correct ?

 

[nector]

Check the versions of access on the different machines.

We are all using the same 365 , could this be a problem?

 

[cheekybuddha]

From the linked article:

Build 17126.20132 released to the Current channel on January 9 fixes this bug.

 

[cheekybuddha]

If you are affected by the bad version (version 2312 Build 17126.20126) then the article shows some workarounds.

Did you read it?

 

[nector]

My question is which version should we use on azure cloud database? the article does not point me to the correct ODBC for assure.

 

[nector]

Finally I have sorted it out by rolling back to this old version 17.10.4.01, never again shall I do an update on the untested version, its like the owners do not fully these programs only when people complain can they fix the bag.

 

[isladogs]

For info, the recent bugs with linked SQL Server connection strings were not related to a specific version of the ODBC driver 17.
See this thread
New Bug - Connection String malformed ! | Access World Forums (access-programmers.co.uk)

 

[GPGeorge]

Hi All

We have a challenge on ODBC for one machine its failing to connect to the database while others are connected see picture . Any solution? the internet is just okay.


View attachment 111946

Coincidentally, I have databases on that same server at Winhost.
"...which version should we use on azure cloud database..." That is not an Azure cloud database, actually. As the name says it's owned by Winhost.com, not Microsoft. But that's not the central point.

I understand you corrected the problem by rolling back the ODBC driver, which is fine. I believe you'll find useful information at AccessForever.org.

To connect to Azure, any of the same ODBC drivers works.

 

[GPGeorge]

Coincidentally, I have databases on that same server at Winhost.
"...which version should we use on azure cloud database..." That is not an Azure cloud database, actually. As the name says it's owned by Winhost.com, not Microsoft. But that's not the central point.

I understand you corrected the problem by rolling back the ODBC driver, which is fine. I believe you'll find useful information at AccessForever.org.

To connect to Azure, any of the same ODBC drivers works.

And Colin beat me to the punchline.

 

[cheekybuddha]

And you're probably better off using MSODBC 18 (after testing, of course!) since MSDOBC 17 is old software now.

 

[isladogs]

And you're probably better off using MSODBC 18 (after testing, of course!) since MSDOBC 17 is old software now.

LOL!

 

[AHeyne]

And you're probably better off using MSODBC 18 (after testing, of course!) since MSDOBC 17 is old software now.

It should be mentioned that a breaking change comes with the ODBC driver 18 for SQL Server.
The connection is now encrypted by default (just in case it doesn't work right away):

The connection encryption defaults have changed. The default value of Encrypt is now Yes, and the new keywords Optional and Mandatory have been introduced as synonyms for No and Yes, respectively.

 

[nector]

Let try ODBC 18 and see the results

 

[nector]

It should be mentioned that a breaking change comes with the ODBC driver 18 for SQL Server.
The connection is now encrypted by default (just in case it doesn't work right away):

Ahyne this seam like the article from winhost suggest

 

[nector]

It only worked for 30 minutes and finally failed , could it its a problem with winhost.com, but I have written to them I'm not getting any reply

 

[GPGeorge]

The

It should be mentioned that a breaking change comes with the ODBC driver 18 for SQL Server.
The connection is now encrypted by default (just in case it doesn't work right away):

The solution is simple though. Add

It only worked for 30 minutes and finally failed , could it its a problem with winhost.com, but I have written to them I'm not getting any reply

If the problem you have is the one I suspect you have, it's a potential security risk and I'm currently re-evaluating my use of SQL Server on Winhost.com because of it.

In a nutshell, Winhost has gone to Self-Certifaction for their SQL Servers. This snippet from this article explains the issue.

Problem with establishing encrypted connection to SQL server from your application

support.winhost.com

Reason:
This error occurs because a self-signed certificate is being used for encrypted connections on our SQL server.

To resolve this issue:
For Classic ASP/ASP.NET/.NET Core applications, update your connection string with the following:
"Data Source=DBSERVERNAME;Initial Catalog=YOURDATABASENAME;User ID=YOURUSERID;Password=YOURPASSWORD;Encrypt=yes;TrustServerCertificate=true"

Note that the last element of their suggested connection string example tells the application to trust their server certificate implicitly, i.e. without verification.

I can no longer connect to any of my Winhost databases from Access without that segment, although the article refers only to web applications.

My understanding is that this is not desirable as it says, in effect, "trust me that I am who I claim to be," without the benefit of a third-party certification.

I've not had time to search for a different hosting company, and given that I'm not risking sensitive data in my personal use databases, I'm not rushing.

However, now that I understand the implications of a self-signed certificate, I'm really going to look for alternatives. I hate the thought because it's such a huge hassle, but in this day and age, complacency is not an option.

So, try that in your connections.

I also would like to solicit input from SQL Server experts who can elaborate more.

 

[nector]

Thank you sir GPGeorge, that make alot of sense.