View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002093||Ham Radio Deluxe||Bug||public||2017-07-04 10:01||2017-08-05 19:00|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Platform||VMware VM||OS||Windows 10 Professional x64||OS Version||10.0.15063|
|Target Version||Fixed in Version||188.8.131.521|
|Summary||0002093: Setup doesn't successfully install Access runtimes when Access is already installed|
|Description||Setup doesn't successfully install the 2007 Access runtimes when Access was previously installed by Office 2016.|
The resulting configuration exposes terrible error handling in the Logbook application.
|Steps To Reproduce||Sorry; I'm including the names of my VM snapshots so I can reproduce this accurately.|
1) Started with bare Windows 10 VM (named "HRD Win 10 Base")
2) Logged in with account that is local admin
3) Installed Office 2016 Pro from web. All defaults. (This is "HRD Win 10 Office Base")
4) Started Access. Noticed that it was a 32-bit process.
5) Quit Access, didn't register or open anything.
6) Installed HRD. All defaults. (This is now "HRD Office Broken")
7) Started HRD.
8) Registered HRD to my K7ZCZ key.
9) Rig control came up with Demo FT-450 Radio
10) Started logbook.
11) Got this error. There is no file named "HRD My Logbook.MDB" in the specified path, but many other files do exist.
Creating: C:\Users\mikeb\AppData\Roaming\HRDLLC\HRD Logbook\HRD My Logbook.mdb
Component not found in the registry
Check that the target folder exists and is not write-locked.
12) Click OK. Same error repeats.
13) Click OK. Same error repeats. Yes, second time.
14) Click OK. Same error repeats. Yes, a third time.
15) Click OK. Same error repeats. Yes, a fourth time time.
16) Click OK. Same error repeats. Yes, a fifth time time.
17) Click OK. A new error appears:
The data source 'HRD Logbook - Access' does not exist.
(#2 - Connect = DSN=HRD Logbook - Access)
18) Finally, no more errors! Press the "ADD (+)" button the the main toolbar to add a contact.
Type in (only) a call sign to the ALE
Press "Add" to add that contact
BUG#3) This message appears. The app should disable its UI if it is not connected to a database.
Error Adding K7DDD - Data source name not found and no default driver specified
|Tags||No tags attached.|
The Logbook calls a function in Setup2.DLL to discover the name of the ODBC driver. When it tries to use the discovered name (in Step #11 of the repro), the name doesn't work and the program can't create the ODBC data source needed.
The Setup2.DLL function finds the driver name by first looking in the registry at a certain key to see what's there. If it finds a name that matches any of a few strings, it returns the first one it finds. IF it can't find any such matching string, it calls the ODBC API to get a list of installed drivers. It searches those for file extensions (like "*.mdb" and "*.accdb") and returns a match.
Thing is, in this scenario -- after installing 32-bit Office 2016 -- the registry search returns a driver name that isn't actually working. The ODBC API does, however, return a usable driver name.
I have a fix coded which will check the ODBC API first, and go directly to the registry if no matches are found. I think checking the registry in any case is completely wrong, but I'm willing to leave the check in to cover scenarios which I can't foresee at the moment. The fix I've coded fixes the above scenario with some caveats.
The first is that the existing code to look at the ODBC API ends up returning a driver name that might not be in English. On my VM, I end up configured with the "Driver do Microsoft Access (*.mdb)". This doesn't seem to have ill effects, and has the very descernable advantage of actually working.
The second issue is that my fix might not work even for the above scenario. I think there's evidence that Setup decides not to install the Access 2007 runtimes shipped with the HRD package in this scenario. I don't know if Setup makes that decision based on this same code in Setup2.DLL, or if it does so on its own. If my checkin changes that, then I might have a surprise. I'm not sure it'll be a bad one, though.
The third caveat is that there might be other or more problems here, and I'm only fixing one. Maybe I'm breaking others!
This is fixed with this checkin: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/3601
The existing code roots around in the registry, makes a guess (a bad one), then proceeds. The fix is to call the ODBC API to enumerate the registered drivers and trust that first; if nothing is found, then consider rooting around in the registry.
If ODBC is broken, the user can fix it with ODBC tools and setup programs. If the registry is trashed, then we've got nobody to blame but ourselves.
||These were all released in the 661 build.|
|2017-07-04 10:01||K7ZCZ||New Issue|
|2017-07-04 13:51||K7ZCZ||Note Added: 0003457|
|2017-07-07 13:55||K7ZCZ||Assigned To||=> K7ZCZ|
|2017-07-07 13:55||K7ZCZ||Status||new => resolved|
|2017-07-07 13:55||K7ZCZ||Resolution||open => fixed|
|2017-07-07 13:55||K7ZCZ||Testing||=> Not Started|
|2017-07-07 13:55||K7ZCZ||Note Added: 0003590|
|2017-07-12 11:05||K7ZCZ||Fixed in Version||=> 184.108.40.2060|
|2017-07-12 11:05||K7ZCZ||Steps to Reproduce Updated||View Revisions|
|2017-07-12 11:05||K7ZCZ||Testing||=> Not Started|
|2017-07-13 23:22||K7ZCZ||Fixed in Version||220.127.116.110 => 18.104.22.1681|
|2017-07-14 16:53||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|
|2017-07-14 16:54||WA9PIE||Target Version||=> 22.214.171.1241|
|2017-07-14 16:54||WA9PIE||Note Added: 0003654|
|2017-07-14 16:54||WA9PIE||Status||resolved => closed|
|2017-08-05 19:00||WA9PIE||Target Version||126.96.36.1991 =>|