| Summary: |
Initializing MySQL/MariaDB database or migrating from SQLite cancels with DB errors |
| Product: |
[Applications] digikam
|
Reporter: |
jeriba4 |
| Component: |
Database-Migration | Assignee: |
Digikam Developers <digikam-bugs-null> |
| Status: |
RESOLVED
FIXED
|
|
|
| Severity: |
normal
|
CC: |
KDE
|
| Priority: |
NOR
|
|
|
| Version First Reported In: |
5.2.0 | |
|
| Target Milestone: |
--- | |
|
| Platform: |
openSUSE | |
|
| OS: |
Linux | |
|
|
Latest Commit:
|
https://commits.kde.org/digikam/9a17c743ea9a41c1ef050b08517343813ef6a9f4
|
Version Fixed In:
|
5.8.0
|
|---|
|
Sentry Crash Report:
|
|
| |
|---|
| Attachments: |
SQL export of initialized Maria DB database up to the errors
|
Created attachment 105044 [details] SQL export of initialized Maria DB database up to the errors Emptied MariaDB (10.0.28-MariaDB) database "digikam" (used with earlier version of digikam) fully accessible by user "digikam" after scheme migration from v7 to v8 failed several times. Even when trying to use this empty DB the following errors occur: digikam.dbengine: Failure executing query: "" Error messages: "QMYSQL: Unable to execute query" "Table 'digikam.Albums' doesn't exist" 1146 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "Migrate_Cleanup_Prepare" ] Statement [ "\n ALTER TABLE Albums DROP FOREIGN KEY Albums_Images;\n " ] digikam.coredb: Core database: running schema update digikam.coredb: Core database: no database file available digikam.dbengine: Failure executing query: "" Error messages: "QMYSQL: Unable to execute query" "Cannot load from mysql.proc. The table is probably corrupted" 1728 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "CreateIndices" ] Statement [ "\n DROP PROCEDURE IF EXISTS create_index_if_not_exists;\n " ] 20 tables and one view are created (including "Albums" mentioned above as being missing). See attachment for the content of the initialized database up to the failure. Tried to workaround by first creating a local SQLite DB and migrate it to the DB server (with a re-emptied DB) => same errors.