"db BUSY" error?


Ken Lemke
 

(If this a dupe, I apologize..) Anyway, I got a warning when I tried to flag a couple of QSOs for upload to eQSL and LoTW...."I am about to reset complex keys in database...db Busy flag is set to false..." I get the same when I attempt to add county info to the logbook entry. I looked at the ADIF file, and it seems that the problematic QSO entries have a highly truncated data set...barely half the data. Also, logger32 wont let me automatically upload to eQSL and LoTW now. Running 3.5xxx, havent uploaded 4 yet. I Cant figure how to clear this...HELP!


Gary Hinson
 

Hi Ken.

 

I’m not sure what you mean by “a highly truncated data set … barely half the data”.  Are those ADIF records valid QSO records with all the essential info?  Perhaps you would share at least one here so we can take a look. 

 

Also, how are you generating the problematic ADIF file from Logger32 v3.5?

 

Garbled QSO records could, I guess, be the result of a problem in the QSO database in Logger32, or a glitch in the ADIF output function.  You could try running it again and checking the ADIF.  It may help to close and reopen Logger32 first.

 

Before anything else, though, I would suggest exporting your entire log as an ADIF and saving that somewhere safe, just in case things go from bad to worse.  Also, if you install Logger32 v4, you can import that ADIF to regenerate your log on the v4 system, or run it through other ADIF-compliant programs (such as ADIFmaster, TQSL or [dare I say it] other logging programs) to check it out and maybe identify and correct or drop the problematic QSO records.

 

73

Gary  ZL2iFB   

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Ken Lemke
Sent: 25 March 2021 09:01
To: hamlogger@groups.io
Subject: [hamlogger] "db BUSY" error?

 

(If this a dupe, I apologize..) Anyway, I got a warning when I tried to flag a couple of QSOs for upload to eQSL and LoTW...."I am about to reset complex keys in database...db Busy flag is set to false..." I get the same when I attempt to add county info to the logbook entry. I looked at the ADIF file, and it seems that the problematic QSO entries have a highly truncated data set...barely half the data. Also, logger32 wont let me automatically upload to eQSL and LoTW now. Running 3.5xxx, havent uploaded 4 yet. I Cant figure how to clear this...HELP!


Ken Lemke
 

By that I meant that each individual record had about half of the ADIF fields...just the basic ones, call, time, etc...The data is accurate, but just missing a lot of typical info.  I would guess most of those that are missing are a result of entering QSL info, so that may not be a valid clue.

I generate the updates to the database like one normally does...putting a call into the logbook entry and hitting enter.  From here, it DOES load into the ADI file, but it will not allow me to load to eQSL or LOTW (LogSync)...that's when I see the error notice i mentioned before.  Also, I get the same notice if I try to update the state or county field via EDIT ADMIN SUBDIVISION tab, which no doubt eliminates LogSync as being at fault.

As soon as I got the error, i did total backup and made several copies of my log file.  Im sure reloading 3.5 will clear the problem, but I hate having to reconfigure everything.  Was hoping someone had seen this before...guess it's a new one, eh?
Ken


Ken Lemke
 

Oh, one more "clue".  When I try to FLAG the record for eQSL or LoTW, I get the error.  Also get the clefer little bug at the top of the error box "Im old and slow" or something to that effect.  It also implies that it's working on the error resolution in the verbiage.


Gary Hinson
 

I’m not sure, Ken.

 

It does sound as if there might be a problem with your software, which reinstalling v3 will hopefully fix.  By the way, the .INI files contain your current configuration, so if you save those and replace them in the Logger32 directory after reinstalling it, you should have your old config back again without having to slog through all the setup options.

 

HOWEVER some problems we see appear to be due to the .INI files themselves!

 

You could also try the v3 to v4 migration process which updates the databases for you, following the instructions in section 2.6 of the Logger32 v4 User Manual

 

In v4, there is also a handy new function to check and optimize the database structure.  See section 8.8 in the manual.

 

73

Gary  ZL2iFB   Today’s on-call L32 support person, it seems!

 

From: hamlogger@groups.io <hamlogger@groups.io> On Behalf Of Ken Lemke
Sent: 25 March 2021 11:49
To: hamlogger@groups.io
Subject: Re: [hamlogger] "db BUSY" error?

 

By that I meant that each individual record had about half of the ADIF fields...just the basic ones, call, time, etc...The data is accurate, but just missing a lot of typical info.  I would guess most of those that are missing are a result of entering QSL info, so that may not be a valid clue.

I generate the updates to the database like one normally does...putting a call into the logbook entry and hitting enter.  From here, it DOES load into the ADI file, but it will not allow me to load to eQSL or LOTW (LogSync)...that's when I see the error notice i mentioned before.  Also, I get the same notice if I try to update the state or county field via EDIT ADMIN SUBDIVISION tab, which no doubt eliminates LogSync as being at fault.

As soon as I got the error, i did total backup and made several copies of my log file.  Im sure reloading 3.5 will clear the problem, but I hate having to reconfigure everything.  Was hoping someone had seen this before...guess it's a new one, eh?
Ken


Ken Lemke
 

Thanks for the great info, Gary.  Will try to get to it tonight and will post results.
73, Ken, AC0DQ


Ken Lemke
 

OK..reloaded 3.5 and no change, so did the upgrade to V4.  Spent most of the morning making the plugins and radio play nice, and think all is well there.  Need to spend time getting WSJT-X to play, and also need to see if I can get JTAert working, as well.  Early on there were several crashes, but it may have been conflict with old version that I hadnt deleted yet.  Seems to be more stable now...think it's resolved.  I DID notice that everything seems to be faster now!  Dont know how much should be attributed to V4 or how much was a problem with my old V3.5...or maybe combo of both.  But so far I'm a happy camper!