Subject Internal gds software consistency check
Author mielhostens
Hi there,

I already posted this remark some days ago but response was not big
so i'll try it again,

Any idea how to solve the problem of getting the error "Internal gds
software consistency check" when looping via an application through
firebird datasets and performing only 1 query on each dataset. I
happens at a random dataset (query works on the specific dataset when
tried seperatly). Adam already did a suggestion about page buffering
but how can i solve this?

Thanx in advance,

Miel

Previous Post:

I recently made a dotnet application which has to query all firebird
datasets in a folder for a specific query and store the results in a
datatable. What i basically do is open and close each database at a
time and loop through the folder with datafiles.

OK, you have used a bunch of .NET jargon here (datasets, datatable,
datafiles). I am going out on a limb here.

I think you mean that you have a bunch of Firebird databases stored in
FDB files in a particular folder. You establish a connection to the
first database and run a particular query against it. You then store
the results of that query in another table (in the same or another
database???, not clear!). You then disconnect and repeat the process
with the next file in that folder.

>
> When i did it with 100 datafiles no problem,
> now i have access to 1000 datafiles and that's when i got the next
> error after a certain database:
>
> Internal gds software consistency check

I am sure there would have been more to that message. Try also
firebird.log.

>
> I first had the idea of a corrupt datafile but when i query the
> datafile alone, it works,... and the funny thing is, it happens to
a
> random database as i also checked this
>
> Anyone who has suggestions?

More information please:

Database server OS: Windows (educated guess)
Superserver or Classic?
1.5, 2.0, 2.1?
32bit / 64bit (Firebird, not your OS)
Anything you have changed in Firebird.conf?
Have you defined page buffers for the databases using gfix?

--
If I had to guess, you are using a 32 bit Superserver build, and the
combined page cache is pushing your process beyond the 2GB memory
limit for a 32bit process.