Ann, (Adam),

>> Had you bothered to read the rest of the thread <g> you would have
>> known that the suggestion to make sure the read-only flag was set
>> stems from the necessity to help the old* transaction counters moving
>> forward, which was the subject of the discussion.

A> Ah yes, the old question of whether you care about accuracy or
A> performance. Unless the report takes hours to run or requires
A> user interaction that could stall its execution, it's not the
A> cause of the stalled OAT.

I don't know if this is the old question you are referring to. Here
what it's all about:

A: I have some long running reports. I also have a huge gap (or gab)
between OIT and NT.
B: Make sure your report transactions are read-only.
A: My report transactions are read committed.
C: mind you, they should be *read-only* read committed.

I am not in a position to defend using the read committed isolation
level for reports; actually I do follow all good practices and use
concurrency for everything I can. Actually I think I am in the
minority by using concurrency for interactive screens as well, but
that's even more OT for this thread.

>> ... BTW, not all reports are affected by the
>> discrepancy problems on Concurrency,

A> I assume you mean the discrepancy problem of read-committed

Yes, sorry.

A> you're right, as long as no piece of data is related to any other
A> piece of data, there's on problem. If, however, you have foreign
A> key relationships, a read-committed transaction may report
A> referencing records without referenced records.

Do you mean in reality or in some lab environment? I fail to see how
you could possibly commit such a relational integrity violation.
Anyway, as I said, I am not going to defend Read Committed; I actually
agree with everything said by you, Adam and Helen in this thread.

I tend to prefer focused and short threads, instead of each topic
becoming a how-to of all Firebird' best practices at large ;-) but I
understand things change with time.

>> and for some reports Concurrency
>> isn't even enough anyway.

A> OK, I'll bite on that one. Can you give me an example of a report
A> where concurrency isn't good enough? I know about update anomalies,
A> but what are the read-only anomalies?

Not read anomalies; I was thinking about phantoms, but actually I
haven't checked whether Firebird's Concurrency level allows them (as
does Repeatable Read in other DBs) or not. Anyway, I can imagine
situations in which Consistency would be required (as otherwise it
wouldn't exist), but they are not exactly "reports" although they
might imply printing.

>> One assumes that if they worked with Read
>> Committed so far then it must be OK for the OP.

A> Or nobody checked.

I cannot put the entire OP's application architecture under x-rays and
find all faults and glitches; at least not in the context of a
newsgroup post. That's what I usually get paid to do and it gets
longer. I might as well shut up next time. ;-)

Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================