Version: (using KDE KDE 3.5.6) Installed from: Debian stable Packages OS: Linux LAST ACTION/CHANGE: I set the root of pictures to a CIFS share which is mounted in fstab as : //Bubblenet/Fotos /mnt/Fotos cifs auto,credentials=/root/.credentials,iocharset=utf8,uid=1000,gid=1000,user 0 0 BUG: starting digiKam I get the error msg: Failed to update old Database to new Database format Then I can click OK and then nothing happens. I cant change the root of the pictures anymore, which might cause the problem. RESOLVING ATTEMPTS (unsuccessful): - Removing the mounted share (to provoke defaulting to home-dir or similar) - Uninstalling with Kpackage (inclunding removing config-files) and then reinstalling! It basically is a dead-lock situation. EXPECTED BEHAVIOR: Give user option to set the root back to the default.
Would it help for you to manually change (usinga a text editor) the "Album Path" in the file ~/.kde/share/config/digikamrc ?
I get the exact same error message without having made any changes (except maybe Digikam had an upgrade in Debian testing, I didn't notice it though). Pictures are all stored on a ext3 local drive, nothing special. following messages show up when run from konsole: foo@bar:~$ digikam digikam: WARNING: [bool Digikam::AlbumDB::execSql(const QString&, QStringList*, bool)] sqlite_compile error: disk I/O error on query: SELECT name FROM sqlite_master WHERE type='table' ORDER BY name; digikam: WARNING: [bool Digikam::AlbumDB::execSql(const QString&, QStringList*, bool)] sqlite_compile error: disk I/O error on query: SELECT value FROM Settings WHERE keyword='Locale'; digikam: No locale found in database digikam: No locale found in config file digikam: WARNING: [bool Digikam::AlbumDB::execSql(const QString&, QStringList*, bool)] sqlite_compile error: disk I/O error on query: REPLACE into Settings VALUES ('Locale','UTF-8'); digikam: WARNING: [bool Digikam::AlbumDB::execSql(const QString&, QStringList*, bool)] sqlite_compile error: disk I/O error on query: SELECT name FROM sqlite_master WHERE type='table' ORDER BY name; digikam: WARNING: Failed to open new Album Database after that the dialog pops up with the 'Failed to update old Database' message. Attempts to resolve: none, way too scared to lose all my tags (again).
Patrick, I have recently reproduce this problem. This is relevant of the write access of you album library path which is in read-mode. The database file is stored in this folder. Check right permossions. Gilles
Gilles, Thank you for pointing me in the right direction! I copied the database around a bit and reset the write permissions for the file and it's directory (even though they where shown as write enabled by ls and Konqueror). Digikam works again here. Patrick
This happens to me almost every few days. The solution that works for me is to delete the journal file, move the database file to a new location and then move it back. Basic idea: rm digikam3.db-journal mv digikam3.db .. mv ../digikam3.db .
kilrae, are you also using a cifs share? This sounds pretty much like NFS to me and presumably has the same problems as NFS because the underlying sqlite database does not work over NFS, see http://www.digikam.org/?q=node/219 If this is correct, then this will be solved with digikam 0.10, see http://bugs.kde.org/show_bug.cgi?id=125474, (and http://www.digikam.org/?q=about/releaseplan).
SVN commit 786717 by abaecker: When upgradeDB_Sqlite2ToSqlite3 fails, this could also mean that the directory with the Album Path is write-protected or does not exist (eg moved by the user). A more verbose error message is given now. BUG: 159467 BUG: 144253 M +4 -1 albummanager.cpp M +1 -0 upgradedb_sqlite2tosqlite3.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=786717
As now a more detailed error description is given (instead of just "Failed to update old Database to new Database format") and the fact that NFS (etc.) is not supported with 0.9.x but for digikam 0.10 (see http://www.digikam.org/?q=about/releaseplan), I marked this bug as fixed. Thanks a lot, Arnd
Marcel, Note that these patches cannot be adapted as well to KDE4. Fine for you ? Gilles
Yes, seems to be fine for me