> Personally I think there should be a big red health warning on any
> kind of validity checking (relying on other records not inserted by
> current transaction) inside normal Snapshot or Read Commited
> transactions.

There IS warning in documentation (not in red though):
----------
Defining a CHECK constraint:
Note: A CHECK constraint guarantees data integrity only when the values being verified
are in the same row that is being inserted and deleted. If you try to compare values in
different rows of the same table or in different tables, another user could later modify
those values, thus invalidating the original CHECK constraint that was applied at insertion
time.
----------

Ivan

----- Original Message -----
From: "johnsparrowuk" <jsparrow@...>
To: <firebird-support@yahoogroups.com>
Sent: Monday, June 14, 2004 4:24 PM
Subject: [firebird-support] Re: Checking periods don't overlap


> Hi Dan,
>
> Thanks for the help. I just wanted to clarify there was no other
> strategy except to use a high-blocking level (table_stability,
> pessimistically locking all rows, etc).
>
> I've suggested a couple of multi-gen solutions, but they're not very
> satisfactory.
>
> Personally I think there should be a big red health warning on any
> kind of validity checking (relying on other records not inserted by
> current transaction) inside normal Snapshot or Read Commited
> transactions.
>
> I've been mistakenly doing this, and I guess so have other people.
>
> John
>
> --- In firebird-support@yahoogroups.com, "Dan Wilson" <dwilson@d...>
> wrote:
> > On 6/14/2004 at 1:32 PM johnsparrowuk wrote:
> >
> > > Well, it's a option in SQL Server 2005 (turned off by default!).
> For
> > > use when 'update conflicts are rare' according to the blurb.
> > > Maintained by using a linked list in tempdb (ewwwwww!).
> > >
> > > I'm prepared to accept FB is the coolest db ever! but...
> > >
> > > Just tell me how I can solve my period-overlap problem???!?!?! :0
> > >
> > > John
> > >
> >
> > John,
> >
> > Isn't this situation what the "snapshot table stability" isolation
> mode was designed to cover? IOW, if you used a read-committed
> transaction to perform your usual checks and interaction with the
> user, then when the user has given their final OK to save the data,
> start a new snapshot table stability transaction which performs one
> final check for conflicts then either save and commit or rollback.
> Or am I missing something obvious?
> >
> > HTH,
> >
> > Dan.