> 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

Reply via email to