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.

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)

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
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.
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

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.

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.

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.