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