Hi,

just to state how things are here: they've got even worse :-/.

We've debugged our application for too many updates on the same
recording during a transaction and found nothing regarding that. But
if our problem stayed with the previous error (internal gds software
consistency check (error during savepoint backout (290)) that wouldn't
be so problematic since the system can continue running with no big
problems.

But now we're also getting in three servers of this client the
following error:

"internal gds software consistency check (wrong record length (183))"

We've got this before in other client and a hardware change fixed it.
But in this new case, *three* servers (all HP servers with less than 1
year of usage) started giving us this problem. The common point is
that all of them share the same database structure and same data
(thanks to the trigger-based replication we've developed in-house).

The transaction volume is around 170000 (thousands) per day on each
server and sadly can't be lower than that by the nature of the
application. I'm really starting to think FB can't handle this client...

I've looked for this error (wrong record length) and found people
saying a wrong client dll (or even using BDE) could cause this problem
with FB, which I find just nonsense since any respectable server
wouldn't let a client damage it's data.

Also found that some people solved the problem by removing some
foreign key. Again, I think this is nonsense since FKs are meant to be
used in the relational paradigm.


So, am I in a dead end?


Regards
Rodrigo