Strange behaviour after database recovery

11 posts / 0 new
Last post
dl8dtl
Strange behaviour after database recovery

Since this is no longer about the option to possibly replace MySQL by something else (see other thread), I think a new thread is more adequate.

After recovering the database from a SQL dump, I'm now facing a strange problem. In some of the logs (but not all of them), when trying to display the QSO list, I get

qCQRLOG : Field not found : "id_cqrlog_main".

Press OK to ignore and risk data corruption.
Press Abort to kill the program.

If I press OK, once that happens, even those logs that used to work well before yield the same message.

Any ideas how to fix it? When looking into the dump, it seems to me this column is actually there in the table, but the sheer amount of data in the table is quite overwhelming, so I'm not fully sure whether I'm looking into the correct place in the dump.

dl8dtl
Update

Update: I don't even think it is related to any particular log. It always happens after switching logs two times.

oh1kh
Strange behaviour after database recovery

HI !

The "QSO list" is problematic. A part of database is captured to grid (max 500 qsos) that is then viewable. When scrolling around qsos cqrlog have to track the block border and load a new one when scrolling goes on.
That had serious problems before, but now they should be fixed.
There is still one known problem left: Qso list has icon "select all qsos". Actually it does not select all qsos in LOG but selects all qsoso in BLOCK that is loaded in. So if you "select all qsos" and then press "delete qso" it will not clean up whole log. Just those ones that currently are loaded in block.

Qso list still has some "hickups". I have noticed that sometimes, but very seldom, there is qso date completely missing (issue #242). When closing cqrlog and opening it again qso date comes back.

That is a good observation that log switching causes problems! I have to keep that in mind.

May I ask do you use official version, or my alpha testing version?
I have noticed that in my alpha, that is in daily use, there are problems with log switching. Mainly so that opening connect database window from new QSO closes all other windows but "forgets" they were open and so next start only New QSO window opens.
I have some test code in open database that I am planning to remove. It does not work properly even when I have spent days for trying to understand how the switching could be done properly. If log switching works within same database engine switches between local and external database engine will again mess it up.

IMHO one of the biggest problems is database open window. The whole cqrlog should be based on that window so that all other windows would be child of that one. Now it is not so and log switching causes problems when coming from NewQSO because NEwQSO should be closed also when switch happens to be sure that all tables are closed.
I do not know cqrlog history from beginning but what I can imagine from pascal unit names the QSO list has been the base of program. Lazarus makes the starting setup so that fist unit is named as "main". Now QSO list has its code in fMain.pas. After that all has grown around it. I think.

Lately I have taken procedure to always close cqrlog and start it again when switching logs. That it not very user friendly but works enough fast and seems to help for this kind of problems.

--
Saku
OH1KH

dl8dtl
version?

May I ask do you use official version, or my alpha testing version?

I think it's an official one …yes, seems so:

ii cqrlog 2.3.0-1~xenial amd64 Advanced logging program for hamradio operators

More observations:

I think it only happens if the QSO list window is opened while switching databases. If I close this window before (and re-open it later), I think I can switch around as many times as I want.

oh1kh
version?

Hey...!

What is that version. Is it really 2.3.0?
If you start it from command console typing:
cqrlog

What does it say?

saku@hamtpad ~]$ cqrlog

Cqrlog Ver:2.5.2 (105) Date:2021-03-18
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****

OS:
Linux version 5.10.15-100.fc32.x86_64 (mockbuild@bkernel02.iad2.fedoraproject.org) (gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9), GNU ld version 2.34-6.fc32) #1 SMP Wed Feb 10 17:52:05 UTC 2021

If it really is 2.3.0 Then expect problems.
You should make update immediately. If your Linux version does not have newer package then you can either compile it by your self or install official binary from my GitHub.

What do you prefer?

--
Saku
OH1KH

dl8dtl
So yes, it's really 2.3.0:

So yes, it's really 2.3.0:


j@wega 201% cqrlog

Cqrlog Ver:2.3.0 (001) Date:2018-06-17
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=1 PARAMETER ****

210408 11:45:06 [Note] /usr/sbin/mysqld (mysqld 10.0.38-MariaDB-0ubuntu0.16.04.1) starting as process 30321 ...
Closing ini file ...

dl8dtl
Installed 2.5.2 from the .tar

Installed 2.5.2 from the .tar.gz file on the download page. (The PPA did not work, but it does not claim support for Ubuntu 16.04 anyway.)
With this version, I cannot switch logs at all. As soon as I try, I get a

List index (0) out of bounds.

Are there any binary downloads in your (OH1KH) github account? Somehow, I didn't find one there … I could try compiling myself, but was too lazy for that right now.

If I ignore the error, I get an empty log list.
When starting afresh, I always get the correct list, and can pick one of the logs.

oh1kh
Installed 2.5.2 from the .tar

Hi!
Download only newupdate.zip from https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
extract and start it. Then you can select what version to install.

How ever I think you database is somehow corrupted. Easiest way to resolve that may be to make full adif exports from all logs with 2.3.0 and perhaps also connect database/utils/configuration/export form log(s) to save preferences typing when creating new empty logs with 2.5.2 and doing adif import after that.

--
Saku
OH1KH

ok2cqr
ok2cqr's picture
Re: Strange behaviour after database recovery

The id_cqrlog_main field is in the cqrlog_main table. But CQRLOG also uses two views created in the database. It seems they are corrupted.

When the cqrlog is running, you can connect to it's server using sock.

mysql -S ~/.config/cqrlog/database/sock

and you should be able to get to the data.

Please go to related log:


use cqrlog001;

where 001 is the number of the log.

Now copy & paste this commands:


CREATE OR REPLACE VIEW view_cqrlog_main_by_qsodate AS SELECT id_cqrlog_main,qsodate,time_on,time_off,callsign, freq,mode,rst_s,rst_r,name,qth,qsl_s,qsl_r,qsl_via,iota,pwr,itu,waz,loc,my_loc,county,
award,remarks, band, dxcc_id.dxcc_ref AS dxcc_ref ,qso_dxcc, profile,idcall, state, lotw_qslsdate, lotw_qslrdate,lotw_qsls, lotw_qslr, cont, qsls_date,qslr_date,club_nr1,club_nr2,club_nr3,
club_nr4, club_nr5, eqsl_qsl_sent, eqsl_qslsdate, eqsl_qsl_rcvd,eqsl_qslrdate,concat(qsl_r,lotw_qslr,eqsl_qsl_rcvd) as qslr,dxcc_id.country, rxfreq, satellite, prop_mode, srx, stx, srx_string, stx_string, contestname, dok, operator FROM cqrlog_main JOIN dxcc_id ON dxcc_id.adif = cqrlog_main.adif order by qsodate DESC, time_on DESC;
CREATE OR REPLACE VIEW view_cqrlog_main_by_qsodate_asc AS SELECT id_cqrlog_main,qsodate,time_on,time_off,callsign, freq,mode,rst_s,rst_r,name,qth,qsl_s,qsl_r,qsl_via,iota,pwr,itu,waz,loc,my_loc,county,
award,remarks, band, dxcc_id.dxcc_ref AS dxcc_ref ,qso_dxcc, profile,idcall, state, lotw_qslsdate, lotw_qslrdate,lotw_qsls, lotw_qslr, cont, qsls_date,qslr_date,club_nr1,club_nr2,club_nr3,
club_nr4,club_nr5,eqsl_qsl_sent,eqsl_qslsdate,eqsl_qsl_rcvd,eqsl_qslrdate,concat(qsl_r,lotw_qslr,eqsl_qsl_rcvd) as qslr,dxcc_id.country, rxfreq, satellite, prop_mode, srx, stx, srx_string, stx_string, contestname, dok, operator FROM cqrlog_main JOIN dxcc_id ON dxcc_id.adif = cqrlog_main.adif order by qsodate ASC, time_on ASC;
CREATE OR REPLACE VIEW view_cqrlog_main_by_callsign AS SELECT id_cqrlog_main,qsodate,time_on,time_off,callsign, freq,mode,rst_s,rst_r,name,qth,qsl_s,qsl_r,qsl_via,iota,pwr,itu,waz,loc,my_loc,county,
award,remarks, band, dxcc_id.dxcc_ref AS dxcc_ref ,qso_dxcc, profile,idcall, state, lotw_qslsdate, lotw_qslrdate,lotw_qsls, lotw_qslr, cont, qsls_date,qslr_date,club_nr1,club_nr2,club_nr3,
club_nr4,club_nr5,eqsl_qsl_sent,eqsl_qslsdate,eqsl_qsl_rcvd,eqsl_qslrdate,concat(qsl_r,lotw_qslr,eqsl_qsl_rcvd) as qslr,dxcc_id.country, rxfreq, satellite, prop_mode, srx, stx, srx_string, stx_string, contestname, dok, operator FROM cqrlog_main JOIN dxcc_id ON dxcc_id.adif = cqrlog_main.adif order by callsign;

It should create new views and the QSO list should work again.

73 Petr

dl8dtl
After reading saku's comments

After reading saku's comments, it's probably not even related to the database recovery, but perhaps a generic issue. It's just I've never been switching around between different logs that much before. I only did it right after the recovery now, in order to verify the recovery worked as intended.

dl8dtl
I'll probably update it from

I'll probably update it from your repo then.
It's a old laptop, and I had difficulties running Ubuntu 20.04 on it, that's why I reverted to 16.04.