At 10:02 PM 26/05/2005 +1000, you wrote:

>Thanks for the reply Paul,
>
>Naturally we do not see the details and extent of this issue that you
>and the FB team would.
>
>Our experience with FB is relatively short so the extent of our exposure
>to this is just what we see on the list.
>
>It may be that we are concerned about nothing after all.

You *should* be concerned, though, to know what *can* stuff up a
database. In the Firebird Quick Start Guide there is a list of ways that
you can do so. They might seem like obviously stupid things for anyone to
do - but the rare cases where Firebird databases have been corrupted
usually turn out to be one of them.

Not mentioned there is the potential for the page inventory to get out of
whack if the database file is allowed to reach the maximum file size limit
for the filesystem that it is stored on. For example, even if the server
is running on an NTFS (Windows) or ext3 (Linux) partition, the database
file will be vulnerable to this kind of mishap if it is stored on a
FAT/FAT32 partition (Windows) or an ext2 partition (Linux).

Another cause of corruption that I have dealt with was one where the
database was on a disk that got damaged by a surge during an electrical
storm. The affected site had been running its software for 3 years and had
never made a backup. They had no UPS. In that time they had also never
run chkdsk or defragged the disk, either.

As a developer and a deployer, it is your responsibility to ensure that you
build in safeguards against user neglect. On some sites, that extends to
giving the "staff hackers" stern warnings about fiddling about with
database settings like Forced Writes, using downloaded tools to mess about
with metadata or "backing up" by taking a zip or filecopy of a database
while there are active connections.

./heLen