Hi mbanaouas,

1e, When faced with "internal gds software consistency check" always check your hardware(RAM/DISK).
In fact if the machine is critical do not accept any "Error" messages
in the OS system error log !

2e, check firebird's "TempDirectories =" the place this looks at should have enough space !

>Is there any way to localize the statement producing this deadlock ?

difficult, but if the statement is actually still running you can use
the monitor tables:


example:

SELECT
STMT.MON$STATEMENT_ID,
att.MON$SERVER_PID,
att.MON$ATTACHMENT_ID,
STATS.MON$PAGE_FETCHES,
STMT.MON$TIMESTAMP,
1000*(CURRENT_TIMESTAMP-STMT.MON$TIMESTAMP) AS SECS,
STMT.MON$SQL_TEXT
FROM MON$ATTACHMENTS ATT
JOIN MON$STATEMENTS STMT ON ATT.MON$ATTACHMENT_ID = STMT.MON$ATTACHMENT_ID
JOIN MON$IO_STATS STATS ON STMT.MON$STAT_ID= STATS.MON$STAT_ID
WHERE ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION
AND STMT.MON$STATE = 1
--AND STMT.MON$SQL_TEXT<> ''

--- In firebird-support@yahoogroups.com, "mbanaouas" <mbanaouas@...> wrote:
>
> Hi,
> I'm facing a deadlock problem:
>
> MYSERVER (Server) Wed Jul 15 16:36:57 2009
> Database: D:\MYFOLDER\MYBASE.GDB
> deadlock
> internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)
>
> MYSERVER (Server) Wed Jul 15 16:36:57 2009
> Database: D:\MYFOLDER\MYBASE.GDB
> deadlock
>
> the 1st log indicate an error while many others follow without error indication. This situation (3 in one month) leads each time it occurs to database repair (hopefully without data loss).
>
> Is there any way to localize the statement producing this deadlock ?
>
> Thanks for any help.
>
> Firebird 2.1.2, Windows 2003 Server
>