TMySQL57Connection error on rename creating new database in EndeavourOS (Arch)

11 posts / 0 new
Last post
N8IW
TMySQL57Connection error on rename creating new database in EndeavourOS (Arch)

I'm attempting a new CQRLOG 2.5.2.001 installation on EdeavourOS (arch) and am receiving the following error during the first time new database creation:

TMySQL57Connection : Error executing query: Error on rename of './cqrlog001/log_changes' to './cqrlog001/#sql-backup-7989-4' (errno: 168 "Unknown (generic) error from engine").
Press OK to ignore and risk data corruption.
Press Abort to kill the program.

MariaDB version = 10.6.3-1

Dave
N8IW

ai7cr
Same issue here on

Same issue here on EndeavourOS (kernel 5.14.3-arch1-1). I was previously on Manjaro (Arch) and had no issues at all. Using MariaDB 10.6.4-1. I tried running with DEBUG=1 but there are no database errors in the log.

W9YA
Confirmed

I can confirm this bug on Manjaro AND Generic Arch-Linux... an existing log can be added to, but a new log cannot be created.

ai7cr
Thanks

Thanks for verifying that. I was about to blow away Endeavour and go back to Manjaro since it used to work there. I've tried all sorts of Mariadb settings and tricks but no luck. Guess I'll hold tight.

Devon44986 (not verified)
Reaction

Thank you for confirming it for us, it was really helpful. I was about to change back and restart again.

oh1kh
TMySQL57Connection error on rename creating new database

Hi!
Without knowing Arch linux I would suggest to check if there is any secure setting that prevents database engine to write ~/.config/cqrlog/database folder.

There is similar known problem with Ubuntu and Mysql 8.0 database engine. I that case using MariaDB instead solves the problem.

Other workaround could be unselect "save data to local machine" and connect the "real" sql server running at localhost, port 3306.
How ever this needs first the creation of database user and privileges for that user that must be done with mysqladmin or command line commands. Cqrlog does not create user but requires it at Database connection window where IP address, port, user and password is asked if "save data to local machine" is not selected.

--
Saku
OH1KH

ai7cr
TMySQL57Connection error on rename creating new database

Thank you for the reply! MariaDB on Arch prevents writing to home directories by default. However, there is a configuration to change that behavior (ProtectHome=false in /etc/systemd/system/mariadb.service.d/.conf). I have mine set up this way.

I don't think that is the issue since the initial database creation gets through much of the process and I see that changes are made in ~./config/cqrlog/database. Running with DEBUG=1, I see that I get the renaming error when this line appears in the log:

ALTER TABLE log_changes
ADD FOREIGN KEY (id_cqrlog_main) REFERENCES cqrlog_main (id_cqrlog_main) ON DELETE SET NULL ON UPDATE CASCADE;

Previous to this, may CREATE TABLE commands complete without error.

oh1kh
TMySQL57Connection error on rename creating new database

Ah...!
"log_changes" table tracks changes to log to keep up list of what have to be uploaded to external online logs (HamQth, Clublog and HrdLog).
I made a search:
[saku@hamtpad cqrlog]$ grep -ni "ADD FOREIGN KEY" src/*.pas
src/dData.pas:2882: Q1.SQL.Add('ADD FOREIGN KEY (id_cqrlog_main) REFERENCES cqrlog_main (id_cqrlog_main) ON DELETE SET NULL ON UPDATE CASCADE;');

And I think this is just the one as there are no others found. When I go to Lazarus and open dData.pas I see that this line 2882 is commented out !! (all blue texts in picture)
That raises a question: How old version of cqrlog you are trying to run?
It certainly is not 2.5.2(001)

You should compile the latest source to get fresh version of cqrlog.
As you now have running cqrlog you just have to load source, compile and install the new one. All dependencies are there already.

These message chains may help to get started:
Raspberry PI 4 and cqrlog https://www.cqrlog.com/node/3124
New Ubuntu and latest cqrlog https://www.cqrlog.com/node/2984
Mint 20 Cinnamon and new cqrlog https://www.cqrlog.com/node/2998

 

--
Saku
OH1KH

ai7cr
TMySQL57Connection error on rename creating new database

It is definitely 2.5.2 (001). From the debug output:
---
Cqrlog Ver:2.5.2 (001) Date:2021-02-12
**** DEBUG LEVEL 1 ****

OS:
Linux version 5.14.8-arch1-1 (linux@archlinux) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1
---

I have been using the AUR package https://aur.archlinux.org/packages/cqrlog-source which is 2.5.2.

Since the package wasn't working I downloaded the source. I found the ALTER TABLE command in dData.lfm, line 404-405. I'm not looking at the Lazarus IDE - just found it in the source. Since the other comments in dData.pas indicate the foreign key is not necessary, I just removed these lines from the .lfm, recompiled, and now the database creation seems to work.

I am getting other errors now though:
When starting: TRasterImage.BitmapHandleNeeded: Unable to create handles, using default

When opening log: Access Violation when executing SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

oh1kh
TMySQL57Connection error on rename creating new database

Hi!

lfm files are normally form design data and I did not expect to find that from there. You are right, it is valid embedded script data there in version 2.5.2

Raster image error comes from GTK2 widgets, I think. I also get some errors all the time to console from graphics but they do not affect cqrlog working.
You could try to install libqt5pas and libqt5pas-dev and then compile with QT5 option ( make cqrlog_qt5 ) to see if QT5 widgets work better.

Does Access violation happen with old log from previous setup , or one that is created with current setup?

--
Saku
OH1KH

ai7cr
TMySQL57Connection error on rename creating new database

Sorry for the delay in response. The access violation happened with a newly-created log after I removed the foreign key lines from the .lfm file.

I never got a raster image error in previous versions and I'm going to assume that it's because of the libraries I have installed locally when I compiled from source. I think the biggest issue right now is the leftover foreign key script lines in dData.lfm.