>On Sun, Mar 9, 2008 at 5:52 PM, Ahmad $arhan **** <mahdoom_a@...> wrote:
>
>> Hi all,
>>
>> My application was working very well, Suddenly the application gave me
>> error msg
>>
>> [General SQL Error
>> internal gds software consistncy check (can't continue after bugcheck)]
>

At 07:42 AM 10/03/2008, Fidel Viegas wrote:

>I have had this problem as well. I posted this problem to
>firebird-devel and explained what I was doing. This is what I got as a
>response: "... each 'internal gds software consistency check' is a
>bug - in theory it
>should not happen. The main problem is how to reproduce it. If you can
>provide a script, reproducing a problem, it will help fixing."

Bugchecks occur when the database engine gets into a state that it cannot deal with. The production code is set to return a Bugcheck, rather than to crash outright and cause a coredump. The engine tries to analyse where and how the condition occurs so, if the engine is still running sufficiently to perform this analysis, there will be "clues" in the message - a number in brackets followed by one or more lines containing a description relating to the clue.

In cases like Ahmad's, where a bugcheck occurs and there are no clues, it is quite likely that the condition occurred because the Firebird server requested more RAM from the OS and it was refused. No RAM == no ability to analyse the fault == no clues reported.

If the engine collapses because of insufficient resources, it is not a "bug" that can be reproduced and fixed by the Firebird developers. Note that, if RAM got exhausted once "out of the blue", it will happen again, next time those conditions occur. The fix is to reconfigure the server resources so that there will always be enough RAM for the service to operate.

You should also check whether another program - such as a filesystem backup utility or an anti-virus program - was running. It is extremely important to exclude your database files and the server's files from such programs. A no-clues bugcheck can occur when such programs lock sectors of your disk that Firebird is using. If the host server is Windows, then many of Microsoft's internal utilities, such as SystemRestore, do not respect file locks that are in use by applications. Some Windows versions allow programs such as Winzip and AV to violate locks unconditionally.

In the "worst case", something happened on the host machine or the network that corrupted data and made it impossible to use the database any more, e.g. damaged sectors on disk or network interference that corrupted a page write. So, before taking the problem to firebird-devel, Ahmad should shut down and restart the server and check whether the application is working.

For any problem report, whether here or in firebird-devel or firebird-test, you are wasting your time and ours if you don't provide proper information about your environment:
-- Firebird version (exact)
-- whether it is SS or Classic
-- OS platform it is running on
-- how many concurrent users were online when the event occurred
-- any excerpts from firebird.log that were written just prior to the problem event (do not post the entire log!!)
-- a copy of the output from gstat -h has the potential to be useful

./heLen