1. An error like that would cause a crash of the process that was
connected to the database - did that happen?
2. I think your problem (in Firebird 1.5.1) is related to the following bug that
is fixed in Firebird 1.5.2 RC3
The server could crash when execute_immediate was used to release or rollback
a transaction to a non-existing savepoint. Not logged
Solution Now fixed. N. Samofatov
Can you download the following 1.5.2 RC3 build and retry the test?
(watch the wrap)
RPM
http://firebird.sourceforge.net/download/prerelease/linux-x86/FirebirdCS-1.5.2.4719-0.i686.rpm
.tar.gz
http://firebird.sourceforge.net/download/prerelease/linux-x86/FirebirdCS-1.5.2.4719-0.i686.tar.gz

Regards
Paul

> I've written some short python code using the kinterbasdb module
> to fill a database table with 600 million records in order to see
> how Firebird behaves with such a huge amount of data. After about
> 430 million inserts (a hard commit after every 10000 records) I
> got the following error:
>
> kinterbasdb.ProgrammingError: (-902, 'isc_dsql_execute: database file appears corrupt (). wrong page type. page 11956216
> is of wrong type (expected 7, found -92). internal gds software consistency check (error during savepoint backout (290)). ')
>
> I thought I'd repair the database with a backup/restore operation,
> so I did:
>
> gfix -validate -full -ignore data.fdb
> gfix -mend -full -ignore data.fdb
> gbak -b -v data.fdb data.gbk
>
> But then I got this error:
>
> gbak: 422260000 records written
> gbak: ERROR: internal gds software consistency check (pointer page vanished from DPM_next (249))
> gbak: ERROR: gds_$receive failed
> gbak: Exiting before completion due to errors
> gbak: ERROR: internal gds software consistency check (can't continue after bugcheck)
>
> What is going on? Did I hit some kind of a limit?
>
> The system is Linux Debian 3.0, the Firebird is
> FirebirdCS-1.5.1.4481-0.i686.
>
> -Ales
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>