Here's the problem. The entries in my CQRlog have been edited to include details about the QSO, comments, and notes. A lot of effort is invested in this.
If I import an ADIF file from WSJTX or Fldigi, there will be dupes. Those imported dupes will be naked QSOs with just the basic info. If I use the Remove Dupes function, I need it to delete only the new naked QSO records. I don't want it to touch any existing QSO records that were already in the log. Does the Remove Dupes function already do this? Does it delete the newly imported QSO or the one that already existed in the log?
Better yet would be an import function that skipped dupes and didn't add them in the first place.
One method I've considered is to create a temporary CQR log file and import to that. Then, using MariaDB, open both databases move rows across only if the QSO doesn't already exist in the main log.
Thank you in advance.
/phil
HI Phil !
Are those old qsos? I suppose so because you can log directly from wsjtx or fldigi to cqrlog. No need to any adif transfers, just use the remote modes.
There is dupe check in adif import. That should prevent duplicates.
I have never used "remove duplicates" so I can not say how it works. I suggest making a full adif export from your log, then import it to new "test" log and you are free to test without spoiling the original log.
As final way if you have some empty fields in all duplicates, but not original qsos, you can create sql command that removes those records " where something='' ". Again, for it you should use first a test log that is copied from original.
--
Saku
OH1KH
Thank you for the reply!
Hmm. I'm not sure whether I've tested the ADIF import in CQR to see if it omits dupes. Every other log program I've used does not and it makes a mess. And with all the discussion here about dupes, I just assumed the import did not check. I shall try it. Rejecting dupes seems obvious to me. I don't know why other log programs don't. I know it slows down the import, but who cares?
Direct connection between WSJTX and my log is sticky because I keep my log on my main machine and the radio setup uses separate machines -- Raspi 3s and 4s, that work great. But I don't keep my main log there. However, I'll think about changing that. I could run everything on the station machines.
I like CQRlog very much and am finally organizing 30 years of logs, so there are all sorts of possible situations. I was describing the current problem with getting QSOs I've made in recent weeks into the log on my main machine.
All the machines are networked together, so maybe there are possibilities. I never even considered connecting WSJTX to CQRlog until now because they're on separate machines. I'll look into that.
However, if the ADIF import rejects incoming dupes, that would solve my whole problem.
Thank you again!
Phil / KW2P
HI Phil!
Yes there is dupe check in import, but you must test it if it works in your case. And do it with test log.
It is no problem to run wsjtx and fldigi on Rpi and cqrlog on other PC. As long as you have network you just put right IP addresses to both ends. Latest cqrlog can also do multicast listening so you can use wsjtx UDP frames at several other programs/PCs.
For fldigi you have to select XMLRPC remote option then it works also via network.
Check NewQSO/Help/Quick start and Operation for wsjt-x and fldigi remotes.
--
Saku
OH1KH
Hi Saku,
I decided to try and get wsjtx talking to CQRlog. I opened the firewalls and configured wsjtx for UDP on the correct port. Then tried to configure CQRlog and after a while realized that my version of CQR (2.0.5) must not support networked operation, only local. Hah.
So, now I'm delving into upgrading to the latest 2.4.X and playing with those problems. I'm running Linux Mint MATE and installed using the Package Manager. I'm debating whether to connect the package manager to Launchpad or to install from the deb I downloaded. Mint ought to be able to install a Ubuntu deb package and directly overwrite the old version. But, I ran into a MariaDB-client error, so I installed libmysql-dev, but then had to go to a Christmas party. Lol. Anyway, I'll get back to you if I run into a problem I can't solve.
/phil
Hi Phil!
OMG! I think 2.4.0(001) is nearly from ice age. :-)
Petr is trying to release 2.5.0 soon and it should use MariaDB as default because of so many problems with Mysql.
Meanwhile the best way is to compile from Github source and install MariaDB manually.
Good luck. Stay safe.
--
Saku
OH1KH
I think 2.0.5 is from 2017. It's the version included in the repos for Linux Mint 19, and with no direct way to upgrade the app. So, I have to do it manually.
What you say is interesting and adds more complexity to my problem. Hah. If I install MariaDB, will it be able to open and work with my existing databases that were created with MySQL? My understanding is that the MariaDB development team tries to stay in perfect step with MySQL so I imagine the answer is yes.
I like changing things one at a time. This is an old preference I picked up in the 1970s when I was involved in building racing engines. If you change more than one thing at a time, then you have no idea why things work better or worse. It's good advice when optimizing engines, but I apply it everywhere.
My system tells me to use...
sudo apt install mariadb-client-core-10.1
...to install MariaDB
My inclination, however, is to try and upgrade CQR first and get it working. Then to change the database.
/p
If you have old Mint with Mysql < 8.0 and you do not plan to upgrade Mint itself it is enough to update cqrlog.
Then you do not have to worry about other databases.
See this thread https://www.cqrlog.com/node/2998 for info how to compile from github.
Another way is to try my ready compiled binary file.
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
"Never touch to working system" is the best advice. Second best is what you say, do just one thing at a time. And sometimes it is needed when working system gets too old.
What ever you do, make proper backups before!
--
Saku
OH1KH
Hello Saku,
I'm running Linux Mint 19.3, which is the latest LTS version. It comes with MySQL 5.7.32.
The next LTS version of Linux Mint is 20.1 but it's still in beta testing. I do plan to upgrade to 20.1 once it's out of beta testing. I assume that Mint 20.1 will include MySQL version 8.
Your comment makes it sound like I should upgrade just CQR for now and leave MySQL in place. When I upgrade in a few months, I can revisit the database problem.
/p
I got kind of an interesting result. I have the deb file for CQR 2.4.0 which is a lot more advanced than 2.0.5 that I've been running.
When I tried to install it, it gave a red error box saying that it's unable to install mariadb-client.
So, I completely removed MySQL and installed MariaDB. That went smoothly, although Synaptic left the apt cache locked, so had to remove the lock.
Then I installed the CQR 2.4.0 deb package and all went smoothly. But when I launch CQRlog, it complains that it can't connect to MySQL.
Of course not. MySQL is gone and replaced by MariaDB. Haha. You can't have MySQL and MariaDB installed at the same time. If I push through the error message, the app is running and looks normal, but has no database connection, of course.
Puzzling this is. Which database engine does it want? Hah.
Hi Phil!
Yep. That is a problem with package installs. They want to fill their own needs..
Even when you have mariadb it is still called mysql. Try console command mysql. it will open mariadb. So no problem with that naming.
When you have clean Mariadb install with same commands as this message https://cqrlog.com/node/2998
You can install cqrlog from tgz file from download page of this forum:
"Complete application directory for other distributions"
When untar this file you should place cqrlog binary to /usr/bin and rest of stuff /usr/share/cqrlog that means that you have to use command argument to strip one directory for tar command if you execure it ar system root "/"
You can also untar it to /tmp and then move files and forders to right directories.
There is a message in this forum, long time ago that tells how to do that. But the search is not easy.
--
Saku
OH1KH
Thanks for sharing your ideas, I hope this would help me also.
concretecontractorswilmington.com