Hi folks,
I'm trying to troubleshoot a problem reported by a Debian user
converting Bacula from Sqlite2 to Sqlite3. The problem is that when you
dump a Bacula database from Sqlite2 and try to load it into Sqlite3,
Sqlite3 crashes because there are fields marked AUTOINCREMENT. Kern has
stated in http://bugs.bacula.org/view.php?id=1351 that there weren't
these, and asked me to follow up here.
Perhaps this wasn't ever in the make tables area, but it sure is there
in the update scripts. I checked this both in a 2.4.4 and a 3.0.2 tree:
jgoerzen:/work/bacula/updatedb$ grep AUTOINCREMENT *sqlite*
update_sqlite3_tables_8_to_9: MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite3_tables_8_to_9: MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite3_tables_9_to_10.in: MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5: MediaId INTEGER UNSIGNED AUTOINCREMENT,
update_sqlite_tables_4_to_5: MediaId INTEGER UNSIGNED AUTOINCREMENT,
etc.
So I believe this debunks the theory that we can convert a Sqlite2
Bacula user to Sqlite3 just by doing what was implied in Bacula #1351:
dumping with sqlite2 and restoring to Sqlite3, which is in fact what we
attempt in Debian:
sqlite "$DB" .dump | sqlite3 "$DB.sqlite3"
So what is the proper way to convert from Sqlite2 to Sqlite3, given
these issues?
For more background:
http://bugs.debian.org/542810
http://bugs.bacula.org/view.php?id=1351
http://article.gmane.org/gmane.linux.debian.devel.bugs.rc/233845
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
