Every time I get the window asking if I want to update the DXCC, and I select yes, the program will go through the list and crash. This does not happen with the QSL Managers...
Here is the output (edited to just the last few entities before the crash):
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-086','Coquimbo / Valparaiso Region group','CE','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-087','Santa Cruz Province North group','LU','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-088','Santa Catarina State South group','PY','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-089','Falcon State group','YV','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-090','Anzoategui State / Sucre State west group','YV','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-091','Magallanes Province group','CE','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-092','Suriname group','PZ','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-093','Choco Division North / Antioquia Division group','HK','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-094','Ultima Esperanza Province South group','CE','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-095','O''Higgins / Maule region group','CE','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-096','Chubut Province North group','LU','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-097','Diego Ramirez Islands','CE','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-098','Arequipa / Moquegua / Tacna Department group','OA','')
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-099','Curacao','PJ2','PJ2')
Aborted
Very strange. I just downloaded new tables and import was without any problem. Are you using full MySQL server or MySQL embedded (default settings)?
It looks like import was aborted but I don't know why. What next cqrlog writes after "Abort"?
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Using a full SQL server, but this happened on my system in 0.9.5 as well. Didn't happen on one of the first betas of ver 1.??...
Nothing is written after abort... the program just dies... Do you want me to delete anything and see what happens? Or send you something?
I have no idea why is this happening. I tried it on four CQRLOG instalations and it worked without any problem. Please look at mysql log if there is any message why was import aborted.
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
I looked for a mysql log and couldn't find any in /var/logs/mysqld - so I don't know what is going on.
Is there a sql command I can run in cqrlog to clear out the old dxcc table first and then reload?
You can delete all DXCC data and IOTA with this command:
Open QSO list window -> Filter -> SQL console
delete from cqrlog_common.dxcc_ref
and
delete from cqrlog_common.iota_list
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
What is the select command I need to run?
Again, crashed at pj2/curacao.
The console won't let you run anything but a select command, so I am not versed well enough in SQL to know what to do (lazy access user here).
It is a bug in SQL console that cause you can use only select statement. I'll fix it.
I have no idea why it is happening. I tried it on several computers and it is working. could you try it with database at your local machine? Maybe there is a problem with connection or database on remote machine.
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Well, everything runs on my local machine - so I am not quite sure what you mean... and like I said, it was like that prior to a full blown mysql installation in 0.9.5... I do know I have a pj2/w5fkx, but I don't think that would cause a problem...
Like I said, it has the option (save log data to local machine) option selected on my logbook...
I'm sorry, I thought you are using MySQL on remote machine. Could you please send me your ADIF file, please? Maybe there is a problem related to your QSOs. I'm sorry about that, I have no idea what could be wrong.
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
I have sent my file along. Hope it helps the program, and isn't just a quirk of my file :)
I disabled "skip-networking" in my.cnf file... when I opened up cqrlog, all of a sudden everything started to import, and also the dxcc tables downloaded and installed without a crash...
Great news! Thank you very much!
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Unfortunately, it still crashes... I ran the mysql command and then there was an error due to a "" in the dxcc table... there were error stacks, and I had to run a corrupted table, then reimport from the ctyfiles directory (which luckily put everything back into order)...
What does the error mean in the beginning here:
[krisbee2010@localhost win_d]$ cqrlog
Loading libssl: /usr/lib/libssl.so.1.0.0
Loading libcrypto: /usr/lib/libcrypto.so
Loading libmysqlclient: /usr/lib/libmysqlclient.so.16
/home/krisbee2010/.config/cqrlog/database/localhost.pid
Command:
kill 2143
110905 16:45:10 [Note] /usr/sbin/mysqld: Normal shutdown
110905 16:45:10 [Note] /usr/sbin/mysqld: Shutdown complete
*
User home directory: /home/krisbee2010/
Program home directory: /home/krisbee2010/.config/cqrlog/
Data directory: /home/krisbee2010/.config/cqrlog/database/
Memebers directory: /usr/share/cqrlog/members/
ZIP code directory: /usr/share/cqrlog/zipcodes/
Binary dir: /usr/bin/
Share dir: /usr/share/cqrlog/
*
/usr/sbin/mysqld --defaults-file=/home/krisbee2010/.config/cqrlog/database/my.cnf --default-storage-engine=MyISAM --datadir=/home/krisbee2010/.config/cqrlog/database/ --socket=/home/krisbee2010/.config/cqrlog/database/sock --skip-grant-tables --port=64000 --key_buffer_size=32M --key_buffer_size=4096K
110905 16:45:13 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
110905 16:45:13 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
110905 16:45:13 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.58' socket: '/home/krisbee2010/.config/cqrlog/database/sock' port: 64000 Mandriva Linux - MySQL Community Edition (GPL)
select * from tables where table_schema = 'cqrlog_common'
SELECT log_nr,log_name FROM cqrlog_common.log_list order by log_nr
The first thing is that even though there is a crash, it does seem to import into the iota table correctly... is this the last table to be updated when you have new dxcc tables/data? If so, I will just live with the crashes, because everything is updating, so it isn't a big deal just running the program a second time after the crash.
However, when I check processes, I see that cqrlog still has something open to mysqld - should I kill that process? Even now, there is cqrlog still holding something open on mysqld...
After cqrlog crashs, mysqld process is still running. So after next run, cqrlog ends old mysqld process and runs new one. You can kill mysqld process but please not with kill -9.
Your problem with crash after importing tables is very strange. I've never met it. Martin OK1RR uses PC LINUX OS which is based on Mandriva and doesn't have any problem.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Yeah, I am not sure what it is - maybe if I compiled on my own machine I wouldn't have an issue but I don't think you have the source out there to do that... however, like I said, if the iota table is the last table to be imported, then I am not really losing anything other than the inconvenience of restarting, which is no big deal.
So, can you confirm the iota table is the last to load in the sequence?
Thanks in advance,
Kris
Yes, it is last loaded table. I was not sure so I had to look to source code and maybe I found why it is happening. Please send me email to petr @ ok2cqr.com with description what architecture are you using. I'll try to do small change into source code and will send you new binary. Strange is that I didn't see it before and don't have the same problem here.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
It just happened again, crashed at Curacao - however, there is no output in /var/log/mysqld... I don't know where else to look for errors.. Should I delete something and reload it? Can there be something wrong in my log?
Okay, so on the iota.tbl if I do a manual import, I noticed that PJ2 has a double-entry at the bottom of the file "PJ2|PJ2" so I fixed that and that made no difference, still having an import error.
So, I deleted PJ2 (since it was the last line) and now SA-098 is the last entity, guess what, errored out!
First abort:
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-099','Curacao','PJ2','PJ2')
Modified table, Second abort:
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-098','Arequipa / Moquegua / Tacna Department group','OA','')
So, it is something about being the last line, I think... however, I deleted all the lines up to sa-055 then, and look at the error here:
INSERT INTO cqrlog_common.iota_list (iota_nr,island_name,dxcc_ref,pref) VALUES ('SA-055','Buenos Aires (Delta Del Parana) Prov group','LU','')
TApplication.HandleException Access violation
Stack trace:
$08065819
$08108B4D
$0807FC5E
$080801CA
$0806C68A
$08245E0D
$0808166E
$0824E978
$08084463
$080A305D
$0825CE2E
$0825D468
$0806C68A
$082F5E59
$0836E782
$B708FADC
Do not change the country files, please, unlesss your fully understand how it works!!! All the files must be intact, the IOTA refers to other tables. Here, the "doubled" PJ2 entry means once the country identifier, the other PJ2 means the prefix (ie. a PJ9 station working from PJ2 country will be NOT resolved properly!). If you are in doubt or you have any correction/addition, email me directly FIRST, before making waves here!
I want to ensure you that if a badly parsed file causes a problem, you will be not alone reporting this 'bug'! If no other users have similar problem, you are probably on the wrong side. Empty (delete all files) the /home/~/.config/cqrlog/ctyfiles folder, downlad the latest country file set from here, unpack the archive into the previously cleaned /ctyfiles folder, start up CQRLOG, import the files and rebuild your DXCC stats. Your problem should disappear...
Nope, same thing.. did it again, and still crashes at the end of the import. Again, if the iota file is the last file it imports, and it crashes at the end of the file, there isn't any real harm... I just want to make sure that is the case, though...