Bug 218571 - schema update version 4 to 5 failed
Summary: schema update version 4 to 5 failed
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Schema (show other bugs)
Version: 1.0.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-13 21:39 UTC by Per Jensen
Modified: 2020-01-01 21:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Per Jensen 2009-12-13 21:39:50 UTC
Version:           1beta5 (using KDE 4.3.2)
OS:                Linux
Installed from:    Ubuntu Packages

digikam suddenly pops up a message, presumably after an ubuntu update, that the "the schema updating process from version 4 to 5 failed"

The program terminates after clicking the "OK" button and write this in the terminal window:

"QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-17499296' is still in use, all queries will cease to work."

This is the only output from digikam to the terminal window.

The dialog box suggests to remove the databasefiles digikam3.db and digikam4.db. If I do so the program indeed starts, but of course with an empty database. 


I have tried to install the newer digikam version 1rc from Luka Renko's PPA at https://launchpad.net/~lure/+archive/ppa - the result is the same.


Any help to fix the schema upgrade is much appreciated - I will be glad to supply any further information/testing in order to solve this bug.

Regards
Per Jensen
per@net-es.dk
Comment 1 caulier.gilles 2009-12-13 22:36:51 UTC
Do not use beta5 but rc. A lots of fix have be done since beta 5

Gilles Caulier
Comment 2 Per Jensen 2009-12-15 14:15:43 UTC
It is the same with Luka's PPA build.

I have now tried to start Luka's version on a backup copy of digikam4.db, and it starts! - I guess this means the "real" digikam4.db is corrupted in some way. It can be opened using sqlite3 though.

If you are interested in finding the cause, I will be glad to help out in any way.

Me losing a months tags is no big deal, not much has changed. Thus I am a happy man again - looking forward to 1.0
Comment 3 Marcel Wiesweg 2009-12-29 15:40:50 UTC
I understand you don't have a backup copy from before your first attempt to upgrade with beta5, but only a broken database from after the upgrade attempt, and an older backup which can be upgraded without problems?
So maybe the original problem is fixed in 1.0?

You could send me the broken database for inspection in any case.
Comment 4 Guillaume Paumier 2010-08-28 19:08:25 UTC
I'm encountering the same problem right now with digiKam Version 1.5.0 (rev.: 1169185). I also tried with the latest svn version (r1169202) but the problem still happens.

I'd be happy to share my database if it can help fix the issue, since I'd prefer not to lose the tagging & metadata work I've been doing (I hadn't sync'd by writing the metadata to the RAW files yet). I don't have a backup of the database before any upgrade was attempted.

My digikam4.db is ~73MB so it's not very convenient to send by email. I can put it on my test server if you want to inspect it.

Also, here's some additional info from the console: 

digikam(11788)/digikam (core) Digikam::SchemaUpdater::updateV4toV5: Dropped triggers
digikam(11788)/digikam (core) Digikam::DatabaseConfigElementLoader::readConfig: "/usr/local/share/apps/digikam/database/dbconfig.xml"
digikam(11788)/digikam (core) Digikam::DatabaseCoreBackendPrivate::debugOutputFailedQuery: Failure executing query:
 "" 
Error messages: "table AlbumRoots already exists Impossible d'exécuter l'instruction" 1 2 "table AlbumRoots already exists" "Impossible d'exécuter l'instruction" QSqlError(-1, "", "") 
Bound values:  ()
digikam(11788)/digikam (core) Digikam::DatabaseCoreBackend::execDBAction: Error while executing DBAction [ "CreateDB" ] Statement [ "CREATE TABLE AlbumRoots
                            (id INTEGER PRIMARY KEY,
                            label TEXT,
                            status INTEGER NOT NULL,
                            type INTEGER NOT NULL,
                            identifier TEXT,
                            specificPath TEXT,
                            UNIQUE(identifier, specificPath))" ]
digikam(11788)/digikam (core) Digikam::CollectionScanner::completeScan: Complete scan took: 368 msecs.
digikam(11788)/digikam (core) Digikam::IccSettingsPriv::scanDirectories: ("/usr/share/color/icc")

If there's nothing you can do, that's ok, I'll get over it :) In any case, I'd like to know what to expect.

Thanks!
Comment 5 Marcel Wiesweg 2010-08-29 10:09:53 UTC
From which digikam version did you upgrade to which when this problem occurred?
Anything special happening?

Since there is a table AlbumRoots, it seems you already have used at least 0.10.0 and had a file digikam4.db. Normally, the v4tov5 update happens from 0.9 and digikam3.db.

Did you create fingerprints for your images? That would explain the size of the db. Or do you have a million pictures?
Comment 6 Guillaume Paumier 2010-08-29 18:32:38 UTC
(In reply to comment #5)
> From which digikam version did you upgrade to which when this problem occurred?
> Anything special happening?

I don't remember anything special happening; I upgraded the digikam package for ubuntu a few weeks ago and got this error.

> Since there is a table AlbumRoots, it seems you already have used at least
> 0.10.0 and had a file digikam4.db. Normally, the v4tov5 update happens from 0.9
> and digikam3.db.

When the v4toV5 schema change happens, is it supposed to keep digikam3.db until the upgrade is completed? Because I don't have a digikam3.db file any more.

> Did you create fingerprints for your images? That would explain the size of the
> db. Or do you have a million pictures?

No, not a million, only ~20 000 :) But I did create fingerprints for them.
Comment 7 Guillaume Paumier 2010-08-29 19:13:27 UTC
FWIW I've decided to lose a few months worth of tags and start over with a new database and the tags saved in the files, but I'm still willing to provide additional information to help fix the issue if needed.
Comment 8 Marcel Wiesweg 2010-08-30 12:15:21 UTC
Yes, the digikam3.db file is never touched, only read. Also note that 0.10.0 was released 17 months ago.

You can open a copy of the digikam4.db file with the "sqlite3" tool and execute:
DELETE FROM ImageHaarMatrix;
VACUUM;
to get a smaller db suitable for emailing
Comment 9 caulier.gilles 2011-12-15 09:16:36 UTC
Guillaume, Per,

This file still valid using digiKam 2.4 ?

Do you see comment #8 from Marcel ?

Gilles Caulier
Comment 10 caulier.gilles 2013-11-20 22:14:47 UTC

*** This bug has been marked as a duplicate of bug 277928 ***
Comment 11 caulier.gilles 2020-01-01 21:43:39 UTC
Not reproducible with 7.0.0 beta1.