View Issue Details

IDProjectCategoryView StatusLast Update
0002093Ham Radio DeluxeBugpublic2017-08-05 19:00
ReporterK7ZCZAssigned ToK7ZCZ 
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
PlatformVMware VMOSWindows 10 Professional x64OS Version10.0.15063
Product Version6.4.0.657 
Target VersionFixed in Version6.4.0.661 
Summary0002093: Setup doesn't successfully install Access runtimes when Access is already installed
DescriptionSetup 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 ReproduceSorry; 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.

[Window Title]
Create Database

[Main Instruction]
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:

[Window Title]
My Logbook

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

TagsNo tags attached.
TestingNot Started



2017-07-04 13:51

administrator   ~0003457

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!


2017-07-07 13:55

administrator   ~0003590

This is fixed with this checkin:

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.


2017-07-14 16:54

administrator   ~0003654

These were all released in the 661 build.

Issue History

Date Modified Username Field Change
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 =>
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 =>
2017-07-14 16:53 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2017-07-14 16:54 WA9PIE Target Version =>
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 =>