Hi Helen,

> >Ann, Helen, can someone help? :-)
>
> Well, I've kept out of it on the basis that inter-row dependencies are IMO
> a sign of poor design. The argument that somehow dirty read would save

the

> day is entirely specious. It would buy the ability to do this unsafe

thing

> at the cost of atomicity. You can't have atomic transactions with dirty
> read, period.
>

--8<-- snipped very valid part about allocating "spaces"

> btw, Martijn, I behold with abject horror any CHECK constraint that checks
> entries against *anything* other than the data in the current row of the
> current table. "Just because you can, doesn't mean you should", like
> sky-diving without a parachute.
>
> Errm, well, you did ask. :-))

Erm, well... But it's properly defined - previously, I mentioned 2 types
of CHECK constraints. I was wrong there - there are 3 types:

1) column check constraints
2) row check constraints
3) database check constraints

the (3) may span the current or other tables. These are completely valid
constraints to give more meaning to your data... Why would you go against
it? (if properly implemented)

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com