Reinstall - Qlog error 'Database migration failed'.

[Petes46]

I reinstalled Mint 22.2. My /home data was preserved on a separate partition but I had to start over installing software. I used AHRL for radio stuff and it installed QLog. Starting QLog throws an error 'Database migration failed', then closes.

I have only been using Qlog for less than a month so losing the database is no big deal.

Question: How do I get QLog to stay up long enough to fix it?

[aa5sh]

I’m not familiar with AHRL other than just hearing about it. But first thing I would do would be to make sure you have the latest version of QLog loaded. When I have seen the ‘Database migration failed’ message it is when I have a newer version database with an older version of the application. Other than that you could rename the database folder in your profile and it should launch with all defaults worse case.

…

On Jan 12, 2026, at 8:14 AM, Petes46 ***@***.***> wrote: I reinstalled Mint 22.2. My /home data was preserved on a separate partition but I had to start over installing software. I used AHRL for radio stuff and it installed QLog. Starting QLog throws an error 'Database migration failed', then closes. I have only been using Qlog for less than a month so losing the database is no big deal. Question: How do I get QLog to stay up long enough to fix it? — Reply to this email directly, view it on GitHub <#889>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXU5GAUBLDTZ5WUKBVD4GOT4JAVCNFSM6AAAAACRNQYBQKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGMZTINRXGI>. You are receiving this because you are subscribed to this thread.

[PY2AD]

The best way to avoid losing your database, or to have a safe reinstallation, is what all logs use:

• Choosing where to create the database (another HDD, SSD, NVMe, pen drive)

• Backups configurable by the program

I myself almost lost my entire log a couple of times because the database creation was automated and it was impossible to choose the location.

I had to adopt the symbolic link method manually, which is quite tedious. Things like this should be the default in the program, and honestly, there are no convincing arguments for why it shouldn't be.

The database is the ham radio operator's treasure; it should be better handled by the software.

[foldynl]

@PY2AD:

Choosing where to create the database (another HDD, SSD, NVMe, pen drive)

It’s interesting how many people worry about this with QLog, but nobody seems to care where their data from Firefox, Chrome or other applications actually lives. To be honest, I do not want to give users too much flexibility here, because from your description it is already clear that it would lead to a kind of creativity which could cause unexpected behaviour, and then I would end up doing nothing but fixing broken or undefined QLog behaviour.

• If you have adopted a symlink, that is your decision. Unfortunately, this is not a method that protects your data. Quite the opposite. Why? Because QLog.db is not a database server, it is a SQLite file. In QLog, SQLite is configured in WAL mode, so the data in QLog.db does not have to be consistent even after QLog is shut down !!!

• Another point is that QLog.db is a binary file that can become corrupted. If it gets corrupted, then the existence of this file guarantees you nothing.

• Another thing is that QLog.db is only a database; it is not your QSOs. It is a file of tables from which only QLog itself knows how to reconstruct your QSOs. No other application can do that.

• Yet another point is that internally QLog behaves slightly differently on Linux, Flatpak, Windows and macOS. These are small things, but if you do not know about them, you can get into trouble.

All of this led me to the decision not to give users the option to manipulate the DB. I really do not see any reason for it. It is an old-fashioned application approach and I do not want to adopt it. DB is an internal DB of application. The common user cannot evaluate the risks associated with manipulating this binary file.

Backups configurable by the program

As for backups, the approach is the same as with all other applications. QLog stores all its data in directories that are normally backed up in some way on all operating systems. That is why I see no reason for QLog to play the role of a backup application. There are other tools for this purpose, such as Time Machine on macOS, various backup applications on Linux, and Windows also has its own home-directory backup. They can handle frequency, scheduling, etc. Why should QLog re‑implement all of this?! Use specialized software for it.

The database is the ham radio operator's treasure; it should be better handled by the software.

The database is not the radio operator’s treasure; the QSOs are. That is why QLog, before every significant database change or, I think, every 7 days, performs an export to ADX and saves it into a directory which, again, is normally included in OS's backups. This export is the radio operator’s treasure, because it can be imported outside QLog. That is the value of this export. And why ADX? Because ADI is crappy. It is an export format that does not handle multi‑language characters and the operator could lose their notes in an ADI export, since QLog exports valid ADI that does not contain UTF‑8 characters based on the ADI standard; BTW It is crazy that in the 21st century there is a widely used export format that does not support UTF-8 characters.

What I register as a "technological debt" is that QLog cannot synchronize QSOs across multiple computers or that there is no tool for migrating from one PC to another. As for synchronization, it has been mentioned here several times, it is something that is beyond my free time, so I do not expect QLog will contain it in the near future. As for PC-to-PC migration, I have something in the devel folder, but unfortunately unexpected problems have occurred in the export and my free time is also very very limited now. But I have marked this as a must-have with a high priority.