Okay, I tried the strategy discussed previously but I'm still having
problems. Either I'm not seeing something, or there's a bug in the
foreign constraint support. Take a look at the following two
execution snippets:
sqlite>
sqlite> commit transaction;
sqlite>
sqlite> begin transaction;
sqlite>
sqlite> DROP TABLE "ParkingLotLevel";
sqlite> DROP TABLE "Car";
sqlite> DROP TABLE "ParkingLot";
sqlite>
sqlite> Commit transaction;
Error: foreign key constraint failed
And now, we switch Car and ParkingLotLevel...
sqlite>
sqlite> commit transaction;
sqlite>
sqlite> begin transaction;
sqlite>
sqlite> DROP TABLE "Car";
sqlite> DROP TABLE "ParkingLotLevel";
sqlite> DROP TABLE "ParkingLot";
sqlite>
sqlite> Commit transaction;
sqlite>
No error! Since the constraints are deferred, the order of the table
drops shouldn't matter, but it clearly does.
I've included a full failing example at the following link. Beware
that it's quite long and full of boring automated code. The
interesting part is right at the end and corresponds with what I wrote
above.
http://patearl.net/files/broken4.txt
This problem (or some variation thereof) has been making me crazy for
the past three days. So nice to finally have a reasonable looking
test case. :)
Patrick Earl
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
