Nando Dessena wrote:

> Helen, Adam,
>
>>> Read only: yes. But !!! Read Committed for reports is terrible
>>> !!! Reports should always use a snapshot transaction (Concurrency
>>> isolation) to avoid getting discrepancies due to database state
>>> changing during execution!
>
> A> Amen!
>
> 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.

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

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

I assume you mean the discrepancy problem of read-committed, and
you're right, as long as no piece of data is related to any other
piece of data, there's on problem. If, however, you have foreign
key relationships, a read-committed transaction may report
referencing records without referenced records. Statistical
results may not match details, etc. Yes, you can probably
program around all that, but only if you anticipate the problems
and have a big programming budget.

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

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

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

Or nobody checked.

Regards,


Ann