QSO confirmation is not saving every time

[9k2hn]

I'm using Ver. 2.32.1.0 (Win 11 PRO 64Bit)
In the qsl manager window when I try to update the confirmation and mark the qso for qsl to be sent to the bureau it is not saving every time, Here is a copy of the realtime log for the same qso after a few retries it worked (for the same qso)

05:55:21.308 Error: [DbSqlite][SaveLog] : [EXCEPTION] database is locked
database is locked
05:55:21.322 Error: [DbSqlite][SaveLog] : SQLITE SaveLog exception while saving Log
[EXCEPTION] database is locked
database is locked
05:55:21.322 Info: * [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd][3435 ms] : Confirmations on 1 QSO for QSL saved successfully
05:55:41.489 Info: [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd] : Updating confirmations on 1 QSO for QSL...
05:55:44.999 Error: [DbSqlite][SaveLog] : [EXCEPTION] database is locked
database is locked
05:55:45.018 Error: [DbSqlite][SaveLog] : SQLITE SaveLog exception while saving Log
[EXCEPTION] database is locked
database is locked
05:55:45.019 Info: * [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd][3529 ms] : Confirmations on 1 QSO for QSL saved successfully
05:55:56.743 Info: [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd] : Updating confirmations on 1 QSO for QSL...
05:56:00.03 Error: [DbSqlite][SaveLog] : [EXCEPTION] database is locked
database is locked
05:56:00.047 Error: [DbSqlite][SaveLog] : SQLITE SaveLog exception while saving Log
[EXCEPTION] database is locked
database is locked
05:56:00.048 Info: * [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd][3305 ms] : Confirmations on 1 QSO for QSL saved successfully
05:56:02.125 Info: [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd] : Updating confirmations on 1 QSO for QSL...
05:56:03.314 Info: * [dje_zM8XFPHK8B8GQPWWLEP8ZHSVJCMHA_ejd][77875 ms] : Recalculating statistics asynchronous process started
05:56:03.319 Info: [dje_zM8XFPHK8B8GQPWWLEP8ZHSVJCMHA_ejd] : Recalculating statistics asynchronous process completed
05:56:03.368 Info: * [dje_zQ6LQ3LUK2LR4X6U5ACPYBUA9N5FQ_ejd][1243 ms] : Confirmations on 1 QSO for QSL saved successfully

I hope I can find a solution for that

Thank you

[G4POP]

As always VERSION NUMBER please


What is the path to your database

[9k2hn]

The version number is in the first line of my post, and the path is c:\Log4om SQlite\9k2hn.sqlite

[G4POP]

Missed the version number, appologies!

Move your database either to a cloud storage like Dropbox because Windows is probably denying access to the file that's located on the C drive

Would be a good plan to update to version 2.33

[9k2hn]

I will update to the latest version and test my next Bureau Patch

Thank you for the reply

[IW3HMH]

database lock is handled by SQLITE driver. That happens when the database file is not accessed properly or the calling application is still "hanged" (Log4Om in this case).
That could happens if the file is temporarily not available so the program connection crashes.

How a database works is a bit complex matter, and Log4OM make use of transactions to make every db connection "reliable".

When a program writes 1 or 1.000 or any other number of rows into a database this operation could be made "row by row" (not transactional). The problem is if the process will fail due bad data at row 144/1000 the database is written with 143 rows, so another write attempt will break things as some of the rows are already in place.
When working "transactionally" all 1000 rows are sent, as before, and stored into a "temporary database" (the lock file). For the application this is completely transparent... when the application successfully wrote all 1000 rows will issue a COMMIT command, and those rows are then stored into the database. If something goes wrong at row 144 the application will issue a ROLLBACK command and those rows will be purged (the lock file is not merged with the database and is dropped).
If your system prevents correct access to the database (e.g. a dropbox sync from another PC actually in use) this could result in a temporarily unaccessible file. If that happens between the "write" and the "commit" the commit will never reach the database and the database is kept "locked" waiting for a COMMIT or a ROLLBACK that will never arrives.

That's a really delicate situation but usually database are able to recover from such situations (by dropping the lock file after some time). Manually deleting the lock file is not recommended (keep a copy of it, eventually) but may works.
Usually the db will auto clean up after some time at the first access.