At 04:45 PM 16/01/2006 +0000, Paul Beach wrote:

> > > > And this is the condition that gave rise to the internal
> > > > inconsistency. AFAIR, it indicates that more than a maximum number
> (256?)
> > > > of updates are pending on the same record. It's never advisable to
> write
> > > > code that performs multiple updates on a record during the same
> > > > transaction: even 2 is one too many.
> > >
> > >Could be me, but I find this silly.
> > >
> > >During the same transaction, if the record is mine, it's mine :-)
>
>Forgive me, but I thought the number above applied to metadata changes and not
>to updates on the same record. I wasn't aware that there was such a low
>limit...
>if there was any limit at all...

I don't *know* what the limit is - that's why I put a guess(?) mark by the
number.

>But then again maybe I have missed something somewhere.
>Althoug I would need to go and do some checking to make sure.

Check the code that throws error 335544663, max_clones_exceeded - afair,
this is related to there being too many recversions of the same record.

./heLen