At 11:35 AM 20/01/2006 +0000, you wrote:

>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?

I suggest that you re-post this message to firebird-devel and see whether
you can catch the attention of a dev. So nobody will jump down your
throat, you can tell 'em I sent you. :-)

Be explicit about

1) the platform, version, build number and model (SS or Classic)
2) the platform[s] of the clients
3) the build number of the client library you have deployed
4) what you are using to interface your programs with the database

Something is occurring to cause consistency problems in the software. 170K
transactions a day is not enormous, certainly nowhere near enough to
challenge the capacity of the engine.

And, while it's a fair statement that a client can't corrupt a database, we
don't see a corrupt database here. We do possibly see corrupt memory
and/or interface structures, though. Your remarks about the BDE seemed
suspiciously defensive. I suppose you do know that there is not a version
of the BDE InterBase driver that fully supports Firebird? (or InterBase >
5.6, for that matter...)

./heLen