> Ok,
>
> sorry if I wrongly presented the exact case.
> I am still worried about the situation when if such corruption occurs
> I cannot give solution to the customer, without contacting third
> party. I will need to clarify this to them - the choice of FB and
> Windows is their's.
>
> So, I will present the case from begining.
>
> Windows 2000, SP4.
> Plenty of disk space, memory, etc.. Not a resource problem.
> The Database was created with FB's isql.
>
> From gstat -h:
> Attributes force write
>
> It has 4 tables and has no Stored Procedures.
> Two generators are used for insertion of unique row ID in two tables.
> 5 indices - 2 on varchar fields, 3 on int fields.

what about the other 2 tables? static content?
How big are the varchar fields you are indexing?
Are there any PKs declared? or just generator field values with no
constraints?

>
> The application uses FB's ODBC driver to connect (via ADO).
> The DB path is kept in registry and is relative to the app location
> (e.g. no connection with different paths can be made).
> DB is local (not remote, shared, mapped, etc. drive)
>

sorry but something smells fishy here...
you say "path relative to the application" - why are you not saying path
absolute to localhost since the server runs on the same machine as the
application?
show us the full connection string you use with the driver.
Are you using the embedded server by any chance?

> The application migrates external data (from DB2 and text files) to
> FB. Each record needs processing and updating by a human. A temp
> table is used to store modified data, which after being validated by

temp table in what form? FB table? text file? or DB2 table?

> the application logic is inserted into FB. Simple inserts statements.
> When the corruption occured, the DB was updated with ~50K rows,
> growing up to 234 Mb on disk.

which method of commit do you use? hopefully hard commit... and how often
thru the processing do you commit?

> The application was closed properly (I can tell this from internal
> logs), including proper connection closing (sure about this!).
>
> I then tried to connect again from a small viewer application and got
> the error. Tried with isql - same. gfix runs with -v -f -i, but
> doesn't fix the Database.
>
> Running IBFirstAid, I found that a page is beyond the end of file,
> i.e. some data was not written to the disk.
>
> Looked in Windows log for some problems - nothing.
>
> Now, something I mentioned in the first post:
> There were 4 huge files (~500 Mb) in the Winnt/Temp dirctory, called
> fb_sort_xxx

You say you insert only? no selects? doesn't sound like you have no select
statemetns... seems like your indexes are not adequate for the queries you
use. Have you examined the plans of the selects?

>
> All my classes have error handling, and if an error is returned by
> the DB, it is written to a log. But there was no error at all while
> inserting data.

are your classes able to log DB engine exceptions? or just class errors?

>
> What I did until now was to use the data in temp table and repeat the
> process on a new DB and all went well. It is almost the same size
> (few bytes difference) from the corrupted one.
>
> I don't know what other details I can provide here...
> I am sure that in the process of inserting data there was no error
> and no other connection to the DB.

not really relevant if there is another connection

>
> The Windows host has no backup software at all, there were no other
> (except the usual) processes running. I checked for viruses with
> Norton and AVG - nothing.
>

Alan