--- In firebird-support@yahoogroups.com, "Jerome Bouvattier"
<JBouvattier@I...> wrote:

> > Jerome, fortunately I did'nt read this book :)
>
> Why "fortunately" ? I think it's a very well done book that goes to

great

> pains to make understable a very tough topic (at least for my simple

mind

> ;-)) : Temporal data (or things that change over time)

Jerome, did'nt you saw ":)"?

> But maybe we are speaking of different things. If you were thinking

about

> MSSQL temporary tables, this is really not what I'm after.

If so, we definitely speak about different things. Perhaps "things
that change over time" mean archieves of changes and their linkage to
get state of data in particular moment in the past? This is another
story...

> Here is the link on amazon :

You want too much from me - to buy and read book in foreign language
with shipping to Russia just to understand what do you you mean :)

> Don't know why I only had IB/FB's snapshot isolation in mind and

forgot

> about dirty read.

Because FB/IB have not dirty read isolation level, I suppose :)
Concurrency (snapshot) read_commited and consistency. IMO best
description of them is in API Guide.

> So, let me rephrase my question.
>
> If my constraints are so that they can't be expressed thru

declarative RI

> but need triggers. Is there a way to avoid the pb described by

Claudio in

> his paper ? That's to say, can I ensure that other connections to my

db

> won't mess up my data integrity by using a different isolation level

than

> "Read committed".

If you _really_ need this, you should provide special access
discipline, or else this attribute-values integrity will be
statistically dependent on intensivity of changes. In some
applications such a check will not be violated just because of nature
of data and access, in others it is issiue of time when integrity will
be violated, maybe once in a century, maybe every day. But usually it
mean it is something wrong in design.

> If not, how comes I often saw non-declarative RI advocated even for
> staightforward RI ?

It is unconditionally correct for linkage tables with dynamically
changed data to "static" directory-kind tables which rows never are
updated or deleted and can only acceppt new entries - inserts. To
safely link two dynamically changeable tables without declarative RI
we should provide some limitations on application, sometimes _very_
sophisticated. One of approches to this I described in
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_lock_records
, sections 5 and 6. But note:
a) it is not reliable - depends on accuracy of application programming
and direct access (via interactive tools).
b) it can be bottleneck in performance and when innacurately
implemented can block all work with database because of deadlocks in
it's classic meaning.

Best regards,
Alexander.