The configuration backup in File -> Oper or create new log -> Utils -> Configuration -> Import does not work. The Export works, it really produces an .ini file but when attempting to load a previously saved configuration it does nothing. No way other than painfully re-enter all settings and prefereces manually.
73,
Martin, OK1RR
Hi Martin!
I have noticed that this have to be done in certain order.
1) set cqrlog so that it does not open recent log at statup, close cqrlog.
2) open cqrlog
3) create a new log
4)click on that log to get it selected (blue)
5) select utils/configuration/import and dig your saved .ini / ok
6) open new log and all settings are there, just tested.
Any other way seems to give wrong result.
--
Saku
OH1KH
Saku,
your presumptions are wrong. Your steps are meaningless on a fresh installation with a new empty log. CQRlog says "Config file imported successfully" but nothing happens, CQRlog does not even know your call!
While playing around this the stupid nightmare label appears again. I am pretty sure that CQRlog does urgently need a maintenance update which will eliminate this TMySQLxxConnection forever. It is the program's bottleneck, also I know a half dozen of potential users who became disgusted seeing this error message. This label often puts CQRlog into disreputation, I was really saddened from comments like
"...oh, they creating not a Swiss knife style logger but a monster covering several nasty digimodes but its base is volatile, precious and the logger has badly maintained its basic functions..."
I am not very optimistic anymore. Somebody calls for contest logging so developers go and create a "contest" option which is nearly useless, its value is nearly tha same as a notepad. There are more rough edges but the basic log file safety and transportability lacks. I suggest to focus our efforts to make CQRlog bomb-proof with the virtually indestroyable content of the log file.
File:
Hi,
i think Martin's idea should be taken up. There's a lot of truth to that. All you have to do is find someone who can do it. I'm afraid I can't do it.
73, Wolfgang
DL2KI
We barely removed the TMSQLXX connection error message because it's a default message produced by MySQL connection routines in Lazarus. When the error message appears during log usage, something got really wrong but unfortunately it's usually in one of threats running on background. It sometimes happens also to me but it's very hard to find out that happened. There are many threads running on background talking with database - dx cluster, RBN monitor, point showing in GrayLine map, log upload, HamQTH/QRZ callbook, band map, country recognition etc. Every threat needs separate dxcc connection. It seems there is a bug somewhere, I probably forget to add critical section somewhere but I have no idea where because there is no way how reproduce the bug :(.
The contest "notepad" is excellent, I use it very often because I participate in contest only as small station with a few hundreds QSO. I have QSO directly in the log and don't have any extra work with import and callbook update. Saku did excellent job.
About the MySQL in CQRLOG. If I could do it again, i wouldn't use MySQL again. It's fine database but when MariaDB appeared there is big mess in libraries and dependencies. There is one horrible false of MySQL. Libraries between version are NOT compatible! We have version 8.0 and I have to wait to FPC developers and make other tweaks to CQRLOG to connect to new database.
Next big problem is with dependency. I can create DEB for Ubuntu but it won't work in Debian and even not in Linux Mint that comes from Ubuntu! It always had different dependency! I really hate that! I don't like releasing new versions because with every release I had to spend hours! testing the package. It's horrible! Without that pain I could release more often without any problem :(. I'm trying to fix it using Appimage or Flatpak but it's a lot of work to get it work :(. I have to create the script to create the package and release of new version will be easy.
Another problem. CQRLOG in Ubuntu repo is old. I have no idea how to replace it with recent version. CQRLOG in default repository is broken and won't work at all.
Do you know what to do? I have no idea. I want to have ONE package for every distro not spend hours testing and it doesn't work at all.
I'll look at configuration loading, I din't know it doesn't work.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Martin,
As I was giving this list of operations to get ini imported to new log I did it at the same time on other desktop. It works, if your database works.
If you do importing in some other order it might not work.
This issue has been discussed here during this year. At that time I tried several ways and found out that ini does not get loaded although cqrlog says ok. Only that order worked every time.
If the database itself does not work properly, as I have here seen in case of many Ubuntu users, even this order does not help.
Actually I think it is not database problem, but problem with Lazarus interfacing the database. Kind a same problem as we have with CQ-monitor color printing with richmemo unit that slowly eats all resources.
If the core of compiler (Lazarus and it's units) fails, there is not much for programmers to do for help. You can't do excellent work with poor tools.
If you mean the contest option of cqrlog, you have not understood what means: "For Sunday operators working in tourist class, do not expect wonders" said in help file.
It SHOULD BE like notepad just giving a running qso number, easier entry of qso data and possibility to export with ADIF for making a cabrillo checklog.
I needed that. Made it for myself and shared it with others in case there might be someone else needing this kind of light notepad for contests (mainly for checklogs). Looks like latest improvements (bug fixes) of it may not any more be added to official version. I do not care... I use contest-option few times a year if I feel l like to work few qsos in some contest.
Same with digi modes. I needed them for myself and shared them, too. I wanted one logger to log all qsos. It happened to be cqrlog. Mainly because it was recommended to me, and because I have made some programming with pascal (Turbo Pascal in DOS environment few decades ago) and this was a good change to introduce Lazarus to myself.
I must say that many parts of cqrlog are still mystery for me. It took quite a long time to clear out how database handling was done (I still do not understand it all) and Polish commenting , still in several places, does not make it easier in any way.
This is not a programming team work. Cqrlog is Petr's project. There are just some contributers trying to add features that they feel are important. And they must rely on what we already have in cqrlog's core.
And what comes to my advices here in forum, they might not be right. Sometimes they are, sometimes not. I'm not a guru, but I feel rather stupid to see many people asking solutions for their problems and nobody does not give any answers.Everyone are just reading and passing by requests for help letting SomeoneOther™ to resolve them.
Even a bad and wrong reply is better than total silence. It may lead to discussion and innovations that finally resolves problem in question.
--
Saku
OH1KH
Saku,
first my sincere thanks for all the work you did for CQRlog. You are very keen and active supporter with highest respect in the CQRlog community and your contribution is highly appreciated. It is a win to have you in our ranks! On the other side, I am co-developer of CQRlog which is a materialisation of my initial thoughts which I tried to realize in Swiss Log (for DOS, 30 years ago), YPlog (by VE6YP, for Windows, 20 years ago - Tony abandoned the program after very bad ski accident which brought him out of the game). My main idea was a reliable, comfortable logger for daily use on CW & SSB with intuitive controls. So, allow me, please, to have influence to the program development, mainly to set the way to go.
Although CQRlog has many nice features and options, it became within years a giant on clay legs. To use MySQL was a brilliant idea, without any doubt. But MySQL is precious, vulnerable software piece with high demand on the user. I am pretty sure that the first task of CQRlog is to SEPARATE the user from any MySQL tasks, commands and problems. No doubt you noticed a half dozen complaints on "Program aborted! TMySQL57Connection : Server connect failed" message. It is a problem which seriously harms the CQRlog reputation, so I suggested to stop adding new features, digital bells and whistles, "contest options" etc. and focus all our power to tune up the code to have an extremely robust and reliable application. Many additions simply came too early, some of them are so simple that a beginner's level program does better (here I mentioned the "contest option" as an example).
I am also sure that a program with basic features will be much easier 'tunable' to reach our target - no data losses, no program abortions due to "TMySQL57Connection : Server connect failed" etc. The program should be able to make heroic efforts to handle user data properly, now is enough if the 400 byte long binary db_version.frm became broken and your whole station log is lost unless you are a well trained mySQL expert who is able to repair it. Anyway, I am sure that the idea "no more TMySQL57Connection : Server connect failed" is very important - we should never see this or similar messages again! The logger should be able to reconstruct the whole working database if the main database file(s) remain unbroken. Now it seems that something marginal and very small can cause data loss!
Configuration data stored in the log MySQL database is very practical but I asked many years ago to store the data in an ASCII text file whioch can be imported into logger. So, we have the .ini file which does not work although CQRlog says that the file was imported succesfully. This is a small example of rough edges which should be fixed first, before other bells and whistles are added.
Unfortunately I am unable to open the sorce code and make these ideas real. My programming skills are neglible. Being 30 years older than Petr I am unable to teach myself or to undertake a course. My brain is not so fresh as it was 30 years ago... I must rely on Petr, on you, on the Polish group of contributors. Although I should keep the 'man in shadow' position, my ideas are not definitely bad. Or ...?
73,
Martin, OK1RR
Hi Martin!
Do not say you are too old and can not open source.
I think we are nearly at same age, retired. No good explanation. Question is about "will" and "want".
But those words include more than what they say. Time sharing between other duties, etc...
Everything you really want, you can do!
But sometimes it is wise (or nice) to leave something for others to do :-)
--
Saku
OH1KH
Old or young, we learn, if we try, can do, probably :) Now, we have to think also, that Petr
has started CQRLOG project in the year "sword and shield". Now distros are developed
enormous hurry. Libraries, not all, but most of them changes quite rapidly. So, one mans shoulders
can't carry that all, tnx Petr for great work, take BUD on me :) What I've seen, biggest problems
with MySQL, MARIADB, has been with *BUNTU distros. As I Fedora user, quite minor. *Buntus
have also most rapid cycle to get new version out, so problem may be there. You "gurus", who have
THE CODE, do not give up, just take vacation and BUD :)
May code be with you
<p>Jarmo</p>
Thank you Petr for all the fine work on CQRLOG, truly a triumph. I too ran into the infamous "TMySQL57Connection : Server connect failed" and no working log after my Mint 19.3 -> 20 upgrade. I suspected a misbehaving mySQL 8.0 was the culprit.
After making sure that my previous ADIF backups were in good order, I uninstalled CQRLOG, and renamed ~/.config/cqrlog to ~/.config/cqrlog-bkp for safety of old settings and data. I removed mySQL and installed Mariadb with any and all parts that looked to be useful. Now I did a clean install of CQRLOG (v 2.4.0) from the Mint 20 repository.
I started the new CQRLOG and made a new and empty database, and successfully imported a backup configuration .ini file. (Backup everything in life, even the config in the "Open create new log" -> Utils -> Configuration -> Export .) Now I had a working CQRLOG, with my old config settings.
Next, I imported a recent backup ADIF of all my contacts. Everything in place!
It seems that CQRLOG will truly successfully import preferences if the database is empty. So that's what you do. Why does it have to be empty, Petr? I really don't know but it seems important to make it work. Then I backed up the config again, and exported a total ADIF again, and felt happier. :) Untidy workaround? Maybe, but Petr's fine CQRLOG now works with Mint 20, complete with its old contacts and preferences. I suspect a similar approach might work for other upgrade troubles with mySQL/mariadb fights in various other "Ubuntoids". Nutt'n' wrong here with mariadb, IMHO.... Just needs to be put back with Synaptic or similar. Start CQRLOG db empty, import the prefs ini, then import the contacts ADIF. Now save it all. Voila! A working CQRLOG in Mint 20. I think Saiku OH1KH had something. -dammit, it works! But why?
Thanks for CQRLOG -it's wonderful! :)
73 John, KX4QC
No birdy aviar soar any wing to eagle it. (J Joyce Finnegan's Wake)
Hi John!
Importing preferences (log settings ini) requires that your log is not open.
I.E. you have to start cqrlog, but not "open the recent log" at Open database window. At that point you can import ini file properly.
If you come from NewQSO/File/Open or create new log you have to first select another log than the open one and you can do importing for that one.
I have a fix branch for preventing settings import to open log, it also prevents deleting open log that is at the moment possible, but there are still other things I'm not happy about and so I have not pull requested it yet to Pet's source.
How ever even importing log settings properly from ini and qsos from ADIF does not give you full recovered log. There are some dates of export/import (eqsl. lotw, clublogs) that are not set by that way.
The only thing to export / import all is mysqldump, or copy ~/.config/cqrlog folder that may not be in question if you switch from Mysql to MariaDB
--
Saku
OH1KH