> Le 6 août 2019 à 14:18, Chris Locke <sql...@chrisjlocke.co.uk> a écrit : > >> I got foreign key constraint failures > > I don't know why one would work and one would fail, but usually, this > occurs when you insert a record which has foreign keys to another table, > but that table hasn't been imported yet. The workaround is usually to > ensure all the 'lookup' tables are done first, so when the main record is > inserted, the required record exists, or to turn off foreign key checks, > and only put them into the database once all the imports have completed.
Of course :), but thanks too, Chris. The real matter at hand is why the script produced by .recover (new feature of 3.29.0) differs from the one produced by .dump to the point that it triggers these 3 constraint failures on this particular db instance I happen to have tested. I have both those scripts and will spend some time looking up where exactly it goes wrong and why. But I wanted to report the strange findings first. Just in case this is well-known and expected in this initial implementation of the .recover command. Indeed, I'm seeing multiple significant checkins about .recover after the 3.29.0 release, so I might first have to rebuild using head of trunk. — Best Regards, Meilleures salutations, Met vriendelijke groeten, Mit besten Grüßen, Olivier Mascia _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
