Ann,

You were right. I checked my code and discovered a possibility of
concurrent record deletion.

So the solution would be to start a READ_ONLY transaction instead
of a READ_ONLY + READ_COMMITTED.
The reason for which I used that mode is because I read somewhere (
perhaps in Hellen Borrie's book ) that when you are planning only to
read records it is more efficient to start a transaction in READ_ONLY +
READ_COMMITTED mode.

¿ Is there any efficiency loss, or some penalty, if you open a
transaction in READ_ONLY mode instead of READ_ONLY + READ_COMMITTED ?

Aldo

El 14/01/11 15:20, Aldo Caruso escribió:

>
> Thank you for your answer.
> Still, those records are neither deleted nor updated until the end of
> the day.
> But I'll check my code if for any reason there is a possibility of an
> update.
>
> Kind regards,
> Aldo
>
> El 14/01/11 15:07, Ann W. Harrison escribió:
> >
> > On 1/14/2011 12:43 PM, Aldo Caruso wrote:
> >
> > > But it seems to me nearly impossible that another transaction could
> > > delete the record in that moment ( because of the business logic,
> those
> > > record aren't deleted until the end of the day ). But I'll continue to
> > > investigate ...
> >
> > Sorry, I was thinking of the way the database works internally. An old
> > record version is deleted when a newer version is committed and visible
> > to all running transactions. The operation that created the new version
> > could be a delete, leaving a deleted stub, or it could be an update. So
> > you'd see that behavior after a committed update.
> >
> > Cheers,
> >
> > Ann
> >
> >
>
> [Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]