Subject | Re: [firebird-support] Frequent database corruption. Anything to do with named cursors? |
---|---|
Author | Helen Borrie |
Post date | 2008-08-18T14:58:14Z |
At 00:32 19/08/2008, you wrote:
./heLen
>Since the improvements to named cursors in FB 2.0x I have re-written..so the page inventory says page 13 is a data page, whereas the engine discovers it's the index root page. Erk.
>some stored procedures to use them, giving massive improvements in
>speed. There was also some stuff which I used to do in the client,
>because it was too complicated for SQL, and named cursors have
>allowed me to move that into the database also.
>
>However, I have now deployed this to a few clients, and some of them
>have started getting repeated database corruption. The error says
>the following:
>
>"Database file appears corrupt
>wrong page type
>page 13 is of wrong page type (expected 5 found 6)
>internal gds software consistency check (error during savepoint
>backout (290), file: exe.cpp line: 3731"
>gfix seems unable to cope with this, and each time I have to pump theIBFirstAid could probably fix it...
>data into a new database, and manually re-create the damaged
>records.
>The corruption always relates to the same table, and thisThis does sound a bit hairy...out of curiosity, why are you operating two cursors on the same table? I can envisage how it would stuff up the savepoint stack - although of course there's something amiss when the engine goes into an inconsistent state as a result of seasickness and corrupts page writes instead of throwing an exception.
>is the table which is most heavily involved in a large and complex sp
>using named cursors.
>
>The sp uses more two cursors simultaneously on the same table. Both
>cursors step through the table, checking that the records in the
>table relate correctly to each other, and updating, deleting or
>inserting as necessary.
>Does anyone have any experience of similar problems with namedIf possible, can you cook up a reproducible test case for the Tracker? (But I'm still interested to grokk why you're trying to row two boats at once...)
>cursors? I guess ultimately there is a FB bug involved, as it should
>not be possible to corrupt a database using SQL alone, and it would
>be useful to know if there are any known problems.
>
>The corruption has occurred on systems using Ver 2.01, 2.03, and
>2.11, so it seems not to be version specific at all.
./heLen