> >> Incidentally, there's a trick for constraints. Execute each constraint
> >> at row level. If it passes, fine. Otherwise track the row id. At
> >> commit time, re-evaluate the failures and act accordingly. This is
> >> probably significantly faster than performing all constraint checks at
> >> commit time.
>
> M> Can't this fail for CHECK constraints that include some kind of
> M> check on multiple rows or existence of rows?
>
> and for FKs as well, not to mention self-reference for that matter.
>
> That's why you retry the failed ones at the end, as I understand.

Hm, but a CHECK can be fine for a single row (while importing),
but not meet the constraint afterwards.

Or can it? Or am I thinking about what the SQL Standard calls
"Assertions" again... Dang.

I'm confused :-)

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com