CQRLOG - bugs

1.0.2 : Rebuilding membership statistic -> SQL error

Hi Petr and Martin,

just decided to switch from 0.9.6 to 1.0.2 running debian SID.. works without any big problems up to now for me. Really like the idea to share a database on a server on demand ;) I'm Running the local datastore variant / i386 tar package.

I installed the Membership Lists of 'Activity Grupp CW (AGCW)' and 'World Flora Fauna' using the default time frame ( 1945-01-01)

Testing QSO view -> Statictics -> Rebuilding membership statistic

in order to build up the AGCW statistic I got an Error message:

>>>

Forums: 

Close cqrlog problem

Hello,

Every time I close the cqrlog the error message pops up: 'Operation cannot be performed on an inactive dataset'. I have two options to chose: "Press OK to ignore and risk data corruption.' or 'Press Cancel to kill the program.' . The only way to close program is kill it. Next time, I use cqrlog every thing works fine. I suppose something like deadlock in my database because program crashed a few times before. Every advice how to check database consistency will be welcomed.

Regards 73

Darek

Forums: 

1.0.0RC1 import problem

I export 15018 entries (as ADIF) in 0.9.6 and import in 1.0.0RC1 and get the notice that there are 21 errors, and when I check I have 15018 - 21 = 14997 records in the new log.

How do I identify and possibly correct the aflicted records?

Other than that so far it seems a great new version - it even allows me to have multiple log without multiple installations to maintain! Now if we could also have some locator statistics and recognintion of propagation mode (important for the VHF/UHF/SHF crowd)

Best 73 de OZ1PIF, Peter

Forums: 

Band map on 20m

Using the latest 1.0.0.~beta1. From Bandmap preferences I have chosen to show the active band and active mode only. On 20 when I click from cluster a 20m phone frequency it shows both CW and SSM frequencies on the bandmap window. If I click CW frequency, it shows only CW frequencies (like it should). Seems to be working OK on other bands, only 20m behaves like this. 73 Pekka OH2BSC

Forums: 

cqrlog does not stay on UTC at winter/summer time changes

When cqrlog does a system call, the kernel gives it the time essentially in UTC.

However, something in the delphi/lazarus implementation underlying cqrlog converts it to localtime, and then cqrlog converts it back to UTC - wrong after a daylight savings time change.

I am sick of losing a few hundred LOTW confirmations on each DST change due to cqrlog doing this idiotic wrong conversion.

Why can't it just get UTC time directly from the OS and do everything in UTC?

Is Delphi/Lazarus so broken that only localtime is supported and not UTC?

Forums: 

Pages

Subscribe to RSS - CQRLOG - bugs