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.