locked Logging Warning: HRD unable to confirm


Mike Wilson <mwilson1946@...>
 

Unsupported ODBC DSN

HRD TCP logging command result =>

 

This error started popping up yesterday after logging about a dozen contacts.

I am using WSJT-X V2.4.0 (c19d62), JTAlert V 2.50.6. Using HRD rig control V 6.7.0.357 for rig control and HRD Logbook (same Version).

 

I have checked everything in all of the configurations and compared with the on-line recommended settings. If I shut down and reboot the PC, usually the logging will work for one or two contacts (but not always), and they the error’s start.

 

What do I do to fix this permanently?

 

73 de KE5WCT

Mike Wilson

Sent from Mail for Windows 10

 

 


HamApps Support (VK3AMA)
 

On 4/10/2021 5:05 am, Mike Wilson wrote:

Unsupported ODBC DSN

HRD TCP logging command result =>

 

This error started popping up yesterday after logging about a dozen contacts.

I am using WSJT-X V2.4.0 (c19d62), JTAlert V 2.50.6. Using HRD rig control V 6.7.0.357 for rig control and HRD Logbook (same Version).

 

I have checked everything in all of the configurations and compared with the on-line recommended settings. If I shut down and reboot the PC, usually the logging will work for one or two contacts (but not always), and they the error’s start.

 

What do I do to fix this permanently?

 

73 de KE5WCT

Mike Wilson


Mike,

I don't know why this is occurring mid session. The setup for HRD logging is occurring when JTAlert is first started and doesn't change for the entire session. I would expect an unsupported DSN error to be shown, if there is a problem, on the first logging attempt after JTAlert startup. This is the first report I have seen of changed behavior mid-session for HRD logging. None of the HRD users on the JTAlert Test team have reported this problem.

There have been a small number of HRD logging problems in recent months that were associated with using MSAccess Logs. Is your HRD log an MSAccess type? If so, the fix in most cases was to perform a full export of the current log, create a new Access log from within HRDLogbook and then import your old QSOs into this new log followed by changing JTAlert to use the new log. In some cases this did not fix the problem, but changing to using a MariaDB log, the format recommended by HRD support, resulted in a guaranteed fix.

Whether a new MSAccess log file or a changeover to MariaDB will fix your problem is unknown due to the uniqueness of your experience.

de Laurie VK3AMA


Mike Wilson <mwilson1946@...>
 

Thank you for replying. I have followed that trail and followed the process of creating a new database (MS Access). I imported the logs (new adif file from another log system (DXKeeper). But that fix only lasted about 15 minutes, then started all over again. The SQL process was going top be my next try.

 

Will let you know the outcome of my efforts.

 

 

73 de KE5WCT

Mike

 

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, October 3, 2021 6:01 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Logging Warning: HRD unable to confirm

 

On 4/10/2021 5:05 am, Mike Wilson wrote:

Unsupported ODBC DSN

HRD TCP logging command result =>

 

This error started popping up yesterday after logging about a dozen contacts.

I am using WSJT-X V2.4.0 (c19d62), JTAlert V 2.50.6. Using HRD rig control V 6.7.0.357 for rig control and HRD Logbook (same Version).

 

I have checked everything in all of the configurations and compared with the on-line recommended settings. If I shut down and reboot the PC, usually the logging will work for one or two contacts (but not always), and they the error’s start.

 

What do I do to fix this permanently?

 

73 de KE5WCT

Mike Wilson


Mike,

I don't know why this is occurring mid session. The setup for HRD logging is occurring when JTAlert is first started and doesn't change for the entire session. I would expect an unsupported DSN error to be shown, if there is a problem, on the first logging attempt after JTAlert startup. This is the first report I have seen of changed behavior mid-session for HRD logging. None of the HRD users on the JTAlert Test team have reported this problem.

There have been a small number of HRD logging problems in recent months that were associated with using MSAccess Logs. Is your HRD log an MSAccess type? If so, the fix in most cases was to perform a full export of the current log, create a new Access log from within HRDLogbook and then import your old QSOs into this new log followed by changing JTAlert to use the new log. In some cases this did not fix the problem, but changing to using a MariaDB log, the format recommended by HRD support, resulted in a guaranteed fix.

Whether a new MSAccess log file or a changeover to MariaDB will fix your problem is unknown due to the uniqueness of your experience.

de Laurie VK3AMA


neil_zampella
 

FWIW ... I'd just stick with the DXKeeper as your logger, much better integration, plus much better support.

Neil, KN3ILZ

Thank you for replying. I have followed that trail and followed the process of creating a new database (MS Access). I imported the logs (new adif file from another log system (DXKeeper). But that fix only lasted about 15 minutes, then started all over again. The SQL process was going top be my next try.

 

Will let you know the outcome of my efforts.

 

 

73 de KE5WCT

Mike


Mike Wilson <mwilson1946@...>
 

The upgrade to SQL appears to have done the trick. So far have operated 5 hours and 40 qso’s with no logging error. It appears to have solved one other minor issue that I have been waiting to get around to addressing.

 

When I lost all of my data (major computer fail, drives fried), I have been unable to rebuild the ‘B4” database. It was my understanding that JTAlert would read the data from what ever logging app that was used if it was on the accepted list. I started off using DXKeeper but the only way the B4 data would update was with the new data from its own log, built in real time though out a comm session. I switched to HRD (for other reasons) but the same thing appeared to going on. The only B4 calls were the ones that I had worked since reloading WSJT-x/JTAlert on the new computer.  All of the methods that I read about on the net for restoration of the B4 database failed.

 

After getting the SQL all set, starting JTAlert, pointing it at the new SQL log in HRD and then restarting JTAlert, the first thing that I noticed was that it spent about 2 minutes scanning the new log (nearly 7000 entries). When the decoded started, bunch’s of B4 calls started appearing. Checking some of them and I found that a couple had not been worked in over a year!

 

So, I opinion the SQL solution not only works, but should be a standard or at least high on the list of things to try with problems occur.

 

Thanks for your help.

 

73 de KE5WCT

Mike

 

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Sunday, October 3, 2021 6:01 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Logging Warning: HRD unable to confirm

 

On 4/10/2021 5:05 am, Mike Wilson wrote:

Unsupported ODBC DSN

HRD TCP logging command result =>

 

This error started popping up yesterday after logging about a dozen contacts.

I am using WSJT-X V2.4.0 (c19d62), JTAlert V 2.50.6. Using HRD rig control V 6.7.0.357 for rig control and HRD Logbook (same Version).

 

I have checked everything in all of the configurations and compared with the on-line recommended settings. If I shut down and reboot the PC, usually the logging will work for one or two contacts (but not always), and they the error’s start.

 

What do I do to fix this permanently?

 

73 de KE5WCT

Mike Wilson


Mike,

I don't know why this is occurring mid session. The setup for HRD logging is occurring when JTAlert is first started and doesn't change for the entire session. I would expect an unsupported DSN error to be shown, if there is a problem, on the first logging attempt after JTAlert startup. This is the first report I have seen of changed behavior mid-session for HRD logging. None of the HRD users on the JTAlert Test team have reported this problem.

There have been a small number of HRD logging problems in recent months that were associated with using MSAccess Logs. Is your HRD log an MSAccess type? If so, the fix in most cases was to perform a full export of the current log, create a new Access log from within HRDLogbook and then import your old QSOs into this new log followed by changing JTAlert to use the new log. In some cases this did not fix the problem, but changing to using a MariaDB log, the format recommended by HRD support, resulted in a guaranteed fix.

Whether a new MSAccess log file or a changeover to MariaDB will fix your problem is unknown due to the uniqueness of your experience.

de Laurie VK3AMA


Roger- AC6BW
 

Hi, Mike,
Glad you got it worked out.
The MySQL database is the way to go.
I've been using WSJT-X, JTDX and JTAlert for years with HRD, using Access and MySQL database, with no problems. Performance with the Access database can depend on a variety of system variables.
FYI, HRD will be discontinuing the Access database, and will be switching to (probably) a MySQL database for all users. This will be in a forthcoming release. Just stay with it, and you will be fine.
--
73,
Roger
AC6BW


Laurie, VK3AMA
 

On 5/10/2021 1:02 am, Mike Wilson wrote:
After getting the SQL all set, starting JTAlert, pointing it at the new SQL log in HRD and then restarting JTAlert, the first thing that I noticed was that it spent about 2 minutes scanning the new log (nearly 7000 entries).
JTAlert doesn't perform any scanning of the log at startup. The first time JTAlert access the log to lookup B4 data is when the first batch of decodes is received. There is no pre-scanning.  What you're describing is not how JTAlert works.

The only time that JTAlert performs a scan of the log at startup is for ADIF logs only and popups up a window to show the scanning progress. If that is what you're seeing, than you don't have logging setup correctly.

Please post an image that shows this scanning activity.

de Laurie VK3AMA