| Subject | Re: [firebird-support] other firebord stability problem : internal gds software consistency check |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-05-07T03:06:31Z |
At 11:45 AM 7/05/2009, you wrote:
The bug is present in v.2.1.x, but is fixed in v.2.0.5. According to the test case, it is occurring when a subquery inside a PSQL block is trying to access a value whose attributes changed due to metadata changes. Previously you were reporting a problem with an index. There is a concern here that you might have ordinary users logged on as SYSDBA and running applications that change metadata: this is NOT a recipe for stability.
From the bug report, the clue is to look for an expression somewhere in your definitions, or in an EXECUTE BLOCK expression in client code, that returns something from a sub-select and uses the result to update a field that is an index key. If you can find such a combination of conditions, you will probably be on the right track to analyse the cause and stabilise your code.
However, nothing becomes obvious until you establish exactly what the user application is requesting at the time the crash occurs.
If it turns out that this bug *is* the cause of your problems and you cannot code your way around it, it might just be simpler for you to go back to v.2.0.5. It should be possible to make a backup of your ODS 11.1 database using the gbak.exe from v.2.0.5 (while v.2.1.2 is running). You should then be able to restore that backup to ODS 11.0 under a v.2.0.5 server.
./heLen
>Hi allThis has nothing to do with the buffer size. Gabor pointed you to this bug report: http://tracker.firebirdsql.org/browse/CORE-2291
>
>i have in last some index error from two day to 5 day
>now i decrese beffer size to 128 page after it after one hour work i get this
>error :
>
>
>Unsuccessful execution caused by a system error that precludes
>successful execution of subsequent statements.
>internal gds software consistency check (cannot restore singleton select data
>(284), file: rse.cpp line: 3426).
The bug is present in v.2.1.x, but is fixed in v.2.0.5. According to the test case, it is occurring when a subquery inside a PSQL block is trying to access a value whose attributes changed due to metadata changes. Previously you were reporting a problem with an index. There is a concern here that you might have ordinary users logged on as SYSDBA and running applications that change metadata: this is NOT a recipe for stability.
From the bug report, the clue is to look for an expression somewhere in your definitions, or in an EXECUTE BLOCK expression in client code, that returns something from a sub-select and uses the result to update a field that is an index key. If you can find such a combination of conditions, you will probably be on the right track to analyse the cause and stabilise your code.
However, nothing becomes obvious until you establish exactly what the user application is requesting at the time the crash occurs.
If it turns out that this bug *is* the cause of your problems and you cannot code your way around it, it might just be simpler for you to go back to v.2.0.5. It should be possible to make a backup of your ODS 11.1 database using the gbak.exe from v.2.0.5 (while v.2.1.2 is running). You should then be able to restore that backup to ODS 11.0 under a v.2.0.5 server.
./heLen