[Digikam-users] How to move a digikam collection

[Thomas]

2012/6/25 Jean-François Rabasse <jean-francois.rabasse at wanadoo.fr>
> On Sun, 24 Jun 2012, Thomas wrote:
>> So, now my question is, how do I get this all up and running again
>> with the collection in the new location and digikam on a new computer?
>>
>> I see that the SQL dump of digikam4.db has this line:
>> INSERT INTO "AlbumRoots"
>> VALUES(8,'photos',0,1,'volumeid:?path=%2Fphotodisk%2Ftdn-photos%2Fphotos','/');
>>
>> Should I just change this to:
>> INSERT INTO "AlbumRoots"
>> VALUES(8,'photos',0,1,'volumeid:?path=%2Fnet%2Fphoto%2Fphotos','/');
>> And then restore the digikam db?
>
>
> Seems good. That kind of tweak works for me, I have similar problems
> when replicating (rsync) DK database between two computers, a desktop
> and a laptop, and yes, I have to change the path of the collection
> base directory.
> A simple command line SQL command can do "UPDATE TABLE ... " etc.
>
> One more thing you should check is the location of your DB file, the
> digikam4.db, because it's stored into the DK runtime configuration
> file, $HOME/.kde4/share/config/digikamrc
> If your DB file is stored at the root of your collection, you'll
> also have to change the "Database Name=" parameter from, e.g.
> /photodisk/photos to /net/photo/photos, so that DK can find your new DB upon next startup.
>
> And if your DB file is on your local computer, not on a USB drive or
> network drive, of course nothing to change in rc configuration.


My DB is on my local computer in ~/Pictures/digikam4.db

I have now tried from a local file system instead of NFS/NAS.

I still get this error from digikam:
digikam(28701)/digikam (core)
Digikam::DatabaseCoreBackendPrivate::checkRetrySQLiteLockError:
Detected locked database file. There is an active transaction. Waited
but giving up now.


Please, is there any way I can just recover all my digikam tags from
the DB, so that I can import them into a new digikam DB?

This stuff needs to be robust. It takes huge amounts of work to tag so
many photos. We cannot let users lose important data like this.