Windows 10: File DSN are slow to scan when opening ODBC Data Source Administrator

When I trigger the opening of the 32-bit or 64-bit ODBC Data Source Administrator, and select File DSN, it takes forever to show the tab.


I see this when I export a table from Microsoft Access to a SQL Server db. That I can discern, this is because the first tab the administrator opens when triggered from Access is the File DSN tab.


There's lots of ways around this relative to the specific issue I have; but, how do I stop the ODBC administrator from taking so long to display File DSNs?

:)

 

Connecting using ODBC File DSN for Lazarus

How to set up ODBC File DSN for Lazarus to MSAccess database?

Please help. Thank you.

 

ODBC Data Sources (32-bit and 64-bit) seem to be the same

There are two applications under Windows Administrative Tools called ODBC Data Sources (32-bit) and ODBC Data Sources (64-bit). But their shortcuts both point to the same file: %windir%\syswow64\odbcad32.exe. I would expect the 64-bit file to have a name
like odbcad64.exe. Why is the same file used for both 32-bit and 64-bit?

BTW, Windows topics (selected below) should have an "Other" selection when the listed selections don't seem to fit the topic being questioned about.

***moved the thread to the nearest category by query.***

 

Suspect configuration of ODBC


I suspect that something is not correct concerning the configuration of ODBC. The Control Panel shows the two entries for this software as it should for a 64 bit system and when you drill down to General under Properties it shows the correct shortcuts for both versions, i.e. system 32 for the 64 bit and SySwow64 for the 32 bit.

When you open up both versions to look at the Administrators, the data appears to be identical for both in some cases. User DSN, System DSN (empty), File DSN, Tracing and About appear to be the same in both. However, in User Data Sources both sets of files are flagged as 32 bit platform and in About all the ODBC Core Components for both versions are pointing to system32 location which is the 64 bit.

For the Drivers tab the 32 bit version is fully populated including SQL Server, most having a version no. of 10.00.1493.00. For the 64 bit version the only entry is SQL Server with the same version.

The same goes for Connection Pooling. The 32 bit version is populated including a SQL Server whereas the 64 bit version only has SQL Server.

Reading various posts online I would expect the 32 bit version to refer to syswow64 files and the 64 bit be populated with the system32 ones if they were there, which they are not.

I also have found the following-:
https://blogs.msdn.microsoft.com/dat...-odbcad32-exe/
Towards the bottom of the first paragraph it says that on a 64 bit system the 64 bit drivers are held at a certain registry location. The registry has the full path but under ODBC Drivers there is only the one entry for the SQLServer which bears out what the Drivers tab is saying above. The 32 bit drivers are there, again confirming the Drivers tab. In the screenshot it shows a typical 64bit system for 64 bit drivers, that data is not in mine.

Below the screenshot it talks about certain registry keys be set to value not set. On my system under 64 bit system and 64 bit drivers, items 1 and 2 are as I have them. For the 32 bit drivers items 1 and 2 again are as per post. However, in both locations ODBCINST.INI and ODBC the 32 bit drivers are fully populated.

To me the 32 bit drivers are in the right place in the registry but not when you look in the Administrators. As for the 64 bit drivers, they appear not to be in the registry nor in the Administrator.

Incidentally, the SQLServer for both versions in the ODBC registry, point to system 32.

This system is an upgrade from Windows 7. Am I wrong in my assumptions or I have missed something, guidance appreciated. If I am correct, how does one resolve this?