When I run Digikam 5.9 the first time, the mysql db is upgraded to v9. The upgrade failed with the error message: Error messages: "QMYSQL: Unable to execute query" "BLOB/TEXT column 'name' used in key specification without a key length" 1170 2 Bound values: () digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV9" ] Statement [ "ALTER TABLE Images MODIFY COLUMN name LONGTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;" ] digikam.coredb: Core database: schema update to V 9 failed! Deleting the guilty index solved the issue for me ALTER TABLE Images DROP INDEX image_name_index; Is that a problem in general or where does my index coming from? Do I need to recreate it manually? PS: I still cannot convert to v9, but these are other issues, to be investigated
Your database is probably very old. I can not reproduce at what time the "name" column in the "Images" table was a BLOB/TEXT field. Log into the database with mysql and do this: UPDATE Settings SET value=9 WHERE keyword='DBVersion'; Create a new digiKam database. Then start digiKam and use the migration tool to export the old current database to the new. Maik
my db is over 12 years old I guess. Looking at the mysql dump, there's indeed alot of garbage (many unneeded constraints and indexes) compared to how a new db looks like. Digikam with db v9 is now running, but I'll probably do the migration to a new db anyways. Just one question: do the ids for the images change during migration? I've added another table (for another project) whos foreign key is images.id. Therefore I currently rely on Images.id not being changed
No, the image ids do not change. Presumably, many orphaned will no longer exist after the migration. The database will certainly be smaller, but nothing should be lost. Maik
Can you reproduce the dysfunction using digiKam 6.0.0 pre-release bundle available here : https://files.kde.org/digikam/
I solved the issue by export/import of the database. That is probably good enough also for other users with this issue. I'm closing this bugreport
workaround in comment #1 is good enough