At 10:12 PM 14/12/2007, you wrote:

>Thanks Helen for your reply.
>
>According to what our customer said there isn't a lot of work going on
>on that database when the problem occurs. It happens at times when
>only very few people are connected to the database.

One person connected to the database could do it, if the error-causing condition comes about from executing a specific routine that is prone to trigger it. It would help you to find a way to get closer to what those users are doing just before the crash happens.

>And because you mentioned "out of memory": This customer we are
>talking about also had memory problems. The database's buffer size was
>too large. So trying to attach to another database on that server
>failed. So we advised them to make the buffer smaller. And so they
>did. Now they can invoke another database connection. But maybe they
>still don't have enough memory - causing THIS error!?

When memory is starved, sometimes one thing leads to another and the straw that breaks the camel's back and produces the inconsistency check is difficult or impossible to track down. Before dying, the engine tries to provide a clue (resulting in the message you see). The scenario that I described to you (or something similar to it) is *one* situation that led to it, but it is by no means the Oh Gosh! answer to a recognised engine condition.

It might be caused by someone making a fresh connection to the *other* database, for example.

>BTW, our customer just updated to 2.0.3 but the problem still exists.
>
>Would it help to run a debug version to gather more infos?

It might; but a debug version has a much larger footprint in memory. Chances are, if they already have memory resource problems, an out-of-memory error could occur sooner and more often, and in a variety of places. Assuming Windows, you would need to run the debug executable in combination with Dr Watson. There's a link to instructions on the Firebird 1.5.5 Downloads page.

>BTW, is it good idea (in this situation) to run a debug version in production
>environment?

A debug build doesn't stop problems occurring; it just provides more verbose information about the crashes. As to impact on users, the obvious thing to do is install the debug exe on your test lab system and compare. If you think the comparative hit on performance is tolerable, you should be able to judge for yourself whether it is a good idea or not to run in on site.

./heLen