> Two questions to get answers to first are:
>
> 1. Is the database file close to, or over, the file system limit
> for the server platform? On Windows or Linux the limit is 2 Gb,
> apparently stretchable to 4Gb if you are using NTFS.

Nowhere near... GDB file size is ~25 meg.

> 2. If the server is on a Windows host, are you certain that all
> users (including those accessing the database with ad hoc client ???
> tools like IBConsole) are using the same, correct connection string
> EVERY TIME?
>
> This is correct (for TCP/IP):
>
> SERVERNAME:DISK:\path\ourdata.gdb
>
> This is incorrect but Windows will let you do it:
>
> SERVERNAME:DISK:path\ourdata.gdb
>
> If you have users mixing these two connection string formats, the
> server treats each client as if it were connecting to its own
> database and irreparable corruption ensues as night follows day.

Really? I thought all that was needed was SERVERNAME: to make the
dclient make the connection to the remote machine's Interbase engine
as a "remote" client.
Very interesting... I have no idea if our installer is setting this
correctly (I'd bet it is, but I'm not 100% sure). Then again, it's
also difficult to rule out the possbility that Joe Schmoe user
changed something after the software got installed, either.
Anyways yes we're running windows. It'd be too complicated to try to
support a database system on Linux, even though we'd like to.

> Next: do you have Forced Writes enabled? If you are using a
> Windows server with Forced Writes disabled, you are skydiving
> without a parachute and hoping to land in a big fat haystack.

I would guess we do, because according to the link posted below,
default on NT/2k machines is forced writes on. The machines that do
all database creation are 2k machines.
However, being as this gdb gets installed on multiple platforms,
depending on the customer (Win98, NT, 2K), it kind of depends on what
the server decides based on it's OS, correct?

> If you have eliminated these recognised sources of corruption, the
> next step would be to look for gremlins in the network hardware
> (esp. if Forced Writes is off).

Hmm.. Not a pleasant thought, but I'll see what can be found out. :)

> These things apart, it's actually pretty hard to corrupt an IB
> database. Generally it will survive someone tripping over the
> server cable or a lightning strike that doesn't burn out the HDD...

That's the impression we were under as well, when we switched to it.
Someone found a story of it being used in tanks, for instance..

> As to rescuing record fragments, that's probably going to be a job
> for an expert if you have already been through the process
> described at http://www.ibphoenix.com/ibp_db_corr.html

We figured out at the end of the day that we could roll the
transaction counters back in the gdb's header and at some point (We
were going by a large number of transactions at a time), the database
became "openable", with more data than we had before. We're going to
be writing a program tomorrow to decrement the counters by one,
attempt to open the gdb file, and then repeat until it can open. The
idea is we can recover as much data as possible using this approach.
I don't suppose anyone else has written this already, or tried, and
figured out that it's not the right thing to do? :)
In any event, thank you for your input. I'm hoping after a night's
sleep everything will somehow magically work itself out. :)

- Jason