Hi Helen,

first thanks for your explanation :-). Now I see things much clear here.

Regarding the problem, what is strange is that it started this week.
And no changes were made regarding user operations or software. So
there is nothing that could explain why such an error would start
happening...

Is there a way to find out which record generated this error? Maybe
using a debug build (it's a production enviroment, so I'm a bit
worried about performance issues in this case)?

I will try finding out when this error happened in the clients, so I
can try to find out which record/table could be the ones causing this
error. I'm also analysing the database with IBAnalyst to try to find
something regarding this issue.

Again, thanks for the help. :-)

Regards
Rodrigo

>
> At 12:08 PM 13/01/2006 +0000, you wrote:
> >Hi,
> >
> >since about a week I'm getting this error in 2 of 7 servers of one of
> >our clients:
> >
> >Database: /manager/gdb/EcomaxUBR2000.GDB
> >operation was cancelled
> >internal gds software consistency check (error during savepoint
> >backout (290))
> >
> >I've seached "the whole net" and found no answer to what may cause
> >this. I'm using the following version of Firebird (on Fedora Core
> >release 3 (Heidelberg)):
> >
> >gfix version LI-V1.5.2.4731 Firebird 1.5
> >
> >Any ideas what may be causing this? This is a 24x7 client and having
> >to gfix the database daily is very problematic to us. Firebird gives
> >me no hint on what may be causing it or where it is happening, so I
> >can't work out the problem...
>
> operation was cancelled
> internal gds software consistency check
>
> This part is telling you that an operation was cancelled as a result

of a

> condition that occurred in the engine that has arisen earlier.

Because the

> engine can't resolve it, it cancels the entire operation where the
> condition arose.
>
> (error during savepoint backout (290))
>
> 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. In any case, it's unlikely to

cause

> corruption, since the cancellation of the operation will undo the

offending

> work. So your daily gfixes (mends?) aren't going to solve anything.
>
> If I'm right about the usual cause of overflowing the savepoints

limit, you

> need to look for something in your application code, trigger code or a
> stored procedure that is potentially going to pile up an exorbitant

number

> of update hits on a single record in a single transaction. Could be a
> logic problem in a FOR loop that's trashing the undo log under certain
> conditions; or some other form of infinite loop...
>
> Are you able to reproduce the problem in your test environment? The

trick

> will be to find out from your customer just which operations most

commonly

> coincide with this message in the log.
>
> And if this turns out to be a red herring, let's look forward to Ann H.
> jumping in and putting her venerable finger on the right button. :-)
>
> ./heLen
>