At 11:52 PM 02-01-02 +0000, polydwarf wrote:

>[big snip]
>
>Has anyone come across anything vaguely similar, or is there some way
>to get record fragments out of a gdb, other than the by-hand method,
>which isn't going to happen? :)
>And on a baser level, if you've seen something like this, what were
>the conditions in which it happened, so we can try to keep it from
>happening again?

Jason,

Because this is a repeating problem, you need to get to the bottom of what is causing the corruption. 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.

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.

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.

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

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

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

regards,
Helen