My 2 cents as well.The old Native Client drivers are affected by this bug as is the even older default SQL Server bug from 2000.
For whatever reason, the newer ODBC drivers such as version 17 aren't affected.
In theory these are also more efficient and have better performance BUT the driver will need to be installed on each user's workstation.
Isn't that what the recent poster said did not work? Maybe he edited the DSN using the DSN tool and since the DSN didn't change, no refresh happened.Actually, you can edit the driver in the connection string using new linked table manager and just refresh the links. No need to delete & re-create from scratch.
Yes, using the RefreshLink method doesn't check for driver changes in the DSN. The DSN connection details once used must be cached somewhere against each table (in particular the driver used). It's similar to the way the username and password credentials are stored somewhere when connecting, yet they are hidden from view and not displayed for obvious reasons. Changing to another DSN certainly forces it to check the DSN details. I'm not sure if changing other details of the connect string would also force it to check the DSN.Isn't that what the recent poster said did not work? Maybe he edited the DSN using the DSN tool and since the DSN didn't change, no refresh happened.