Hei Jan!

Hej!

 

The one thing I try to avoid, is running DDL (CREATE, ALTER, DROP <table|trigger|stored procedure) on a database in use. Maybe I'm overly careful, but not all too long ago, a colleague caused some problems when he did

ALTER MyTable DROP MyField;

while he simultaneously had another transaction having uncommitted changes to MyField in one record.

 

We never do that. All our database upgrades takes place just after our middleware has started and before we give any access to the other parts of the system, so this is probably not the explanation for our problems, since there is always just one transaction running when we are modyfying the data model.

 

I think (but have no experience), that possible reasons for corruption could include file system backups of the database while it is in use (exclude the database file(s) from such backups, rather use gbak for the backup, and include the resulting file in the system backup),

Since we target a market consisting of normal end users it is hard for us to exclude our files from backups that our customers are performing. We can instruct them to do that, but we can never be sure that they follow our instructions. Also I can understand that the Firebird database files could become corrupted if you performed a (non-consistent) backup of them and then read back this backup into the production system, but we are seeing these corruptions on non backed up database files.

 

and possibly anti-viruses preventing Firebird from doing it's work (though I would expect this to result in the database being unaccessible, not corrupted).

Another thing that's only affecting Fb 2.5.1, is that this version has an error relating to compund indices (requiring backup/restore or rebuilding such indices if upgrading to 2.5.2). Though I doubt this error would cause data corruptions involving more than the index.

Others will be able to give you a more thorough answer, despite having used Firebird since it's inception (0.9.4), I've very little experience with corruptions (undoubtedly related to only working on a handful of databases with about 20 simultaneous users).

HTH,
Set