Ultimately, of course, you know vastly more about the implementation
that I do. But then I'm not concerned with how it's achieved...

If it's not possible to achieve this without table_stability
isolation, fair enough.

But it's not an unreasonable thing to ask for!

In this case FB would seem to be more blocking that SQL Server, which
is saying something...

John


--- In firebird-support@yahoogroups.com, "johnsparrowuk"
<jsparrow@e...> wrote:

> My point is that check constraints should work in a way consistent
> with indexes, which at the moment they don't.
>
> From testing I can see that a unique index can see uncommitted

values

> in another transaction. It can also see committed values that have
> been deleted in another transaction (the point you make). But as

soon

> as that other trans commits the delete, I am allowed to insert the
> new record without restarting the other (snapshot) transacton.
>
> It depends on your definition of 'dirty read' I suppose. The jargon
> was developed before multi-gen systems were designed I guess, so
> there could be some confusion.
>
> John
>
> --- In firebird-support@yahoogroups.com, "Ivan Prenosil"
> <Ivan.Prenosil@s...> wrote:
> > You seems to believe that e.g. unique constraint could be written
> > as check constraint that can read uncommitted data ? NO way.
> > Dirty-read would read just last (be it committed or uncommitted)
> record version,
> > whereas unique constraint will check whole chain of versions.