Failure to upgrade database from 4.* to 5.* (scheme version 7 to 8)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Failure to upgrade database from 4.* to 5.* (scheme version 7 to 8)

Johannes Graumann-2
Hello,

Approximately a decade worth of diligent image tagging is at risk given the
fact that on my Debian stable/testing system, I do not manage to convert the
mysql digikam back end in the process of upgrading to digikam 5.* - please
help!

When starting digikam v5.* pointed at the 4.*-used database backend I get the
following:

> digikam.dbengine: Loading SQL code from config file
> "/usr/share/digikam/database/dbconfig.xml" digikam.dbengine: Checking XML
> version ID => expected:  3  found:  3 digikam.coredb: Core database:
> running schema update
> digikam.coredb: Core database: have a structure version  7
> digikam.coredb: Core database: makeUpdates  7  to  8
>
> digikam.dbengine: Failure executing query:
>  ""
>
> Error messages: "QMYSQL: Unable to execute query" "Can't DROP
> 'Albums_AlbumRoots'; check that column/key exists" 1091 2 Bound values:  ()
> digikam.dbengine: Error while executing DBAction [ "UpdateSchemaFromV7ToV8"
> ] Statement [ "ALTER TABLE Albums\n                                      
> DROP FOREIGN KEY Albums_AlbumRoots;" ] digikam.coredb: Core database:
> schema update to V 8 failed!
> digikam.coredb: Core database: cannot process schema initialization

When explicitly trying to use the db migration tool included into 5.* I end up
with this error:
> Error while converting the database.
> Details: Cannot add or update a child row: a foreign key constraint fails
...
There's an image documenting the complete error here: https://
i.stack.imgur.com/wyjNn.png (I already asked at stackexchange before seeking
help here - no takers).

Thank you for any pointers - a not insignificant part of family history is
locked into that database ...

Sincerely, Joh
Reply | Threaded
Open this post in threaded view
|

SOLVED: Re: Failure to upgrade database from 4.* to 5.* (scheme version 7 to 8)

Johannes Graumann-2
On Monday, September 26, 2016 1:33:47 PM AST you wrote:

> Hello,
>
> Approximately a decade worth of diligent image tagging is at risk given the
> fact that on my Debian stable/testing system, I do not manage to convert the
> mysql digikam back end in the process of upgrading to digikam 5.* - please
> help!
>
> When starting digikam v5.* pointed at the 4.*-used database backend I get
> the
> following:
> > digikam.dbengine: Loading SQL code from config file
> > "/usr/share/digikam/database/dbconfig.xml" digikam.dbengine: Checking XML
> > version ID => expected:  3  found:  3 digikam.coredb: Core database:
> > running schema update
> > digikam.coredb: Core database: have a structure version  7
> > digikam.coredb: Core database: makeUpdates  7  to  8
> >
> > digikam.dbengine: Failure executing query:
> >  ""
> >
> > Error messages: "QMYSQL: Unable to execute query" "Can't DROP
> > 'Albums_AlbumRoots'; check that column/key exists" 1091 2 Bound values:
> > ()
> > digikam.dbengine: Error while executing DBAction [
> > "UpdateSchemaFromV7ToV8"
> > ] Statement [ "ALTER TABLE Albums\n
> > DROP FOREIGN KEY Albums_AlbumRoots;" ] digikam.coredb: Core database:
> > schema update to V 8 failed!
> > digikam.coredb: Core database: cannot process schema initialization
>
> When explicitly trying to use the db migration tool included into 5.* I end
> up
> with this error:
> > Error while converting the database.
> > Details: Cannot add or update a child row: a foreign key constraint fails
>
> ...
> There's an image documenting the complete error here: https://
> i.stack.imgur.com/wyjNn.png (I already asked at stackexchange before seeking
> help here - no takers).
>
> Thank you for any pointers - a not insignificant part of family history is
> locked into that database ...
>
> Sincerely, Joh

Using the advise given here http://stackoverflow.com/a/39706451/2103880 (which
points to here https://bugs.kde.org/show_bug.cgi?id=355831#c73 ), I have
purged all inconsistencies from my DB and have now successfully upgraded to
schema v.8.

Joh