Actually, I've never had a corrupted firebird database. There were two bugs in an older version of InterBase that produced income for me.
The first was a failure to realize that a file had just gone over 4Gb and therefore the word holding the offset had rolled over and the system had begun writing at the beginning of the file. Nasty. The second was a case that allowed a server to open a single database twice, thinking it was two different databases. That lead to doubly allocated pages which lead to wrong page types, etc. Both problems were fixed before the first version of firebird shipped.
On the larger question of embedded database code, yes, there is certainly the possibility of user data overwriting database data structures, accidentally or intentionally. The intentional part is a question for the builders and users of the application. Only trusted programs should ever run with an embedded engine. The accidental part rarely, if ever corrupts a database for two reasons.
First, there's quite a lot of checking internally. A trashed data structure is recognized quickly and shuts down the connection without writing anything. Reestablishing the connection creates an entirely new set of internal structures, disposing of the corruption.
Second, the database is always (in almost all circumstances) consistent, even if uncommitted data must be written. Our goal, from the beginning, was to allow the database to restart instantly from a crash caused by tripping over the power cord of the server. It works, except in one actual and one theoretic case.
We offer an asynchronous write mode because flushing files on Unix systems is too expensive. (The system was originally written for VMS, which didn't have a page cache.) On Unix systems, the careful write is almost always successful enough even asynchronously because pages aren't kept in the system cache for long. That's the theoretic case. The actual case is on windows which, by default, keeps pages in cache until process shutdown. Pulling the plug on a windows system that's using asynchronous writes is the actual problem.
Fortunately, people have learned not to run power cords from their servers across corridors and such, so the "tripped over the power cord" problem is much reduced from years past. However, in areas with frequent power failures, there are occasional broken databases caused by pages that were in the cache and not written. Generally, that happens in less developed countries where the cost of a UPS is significant. Needless to say, the cost of having me repair the database is also significant. Often, after the user pleads and grovels on the subject of not having a UPS or a database backup, I fix those for free. Harrison's campaign for world harmony. Don't tell my boss.
Firebird and InterBase have been used in "embedded" mode since 1985 and don't seem to corrupt data except in the cases described above. The next version of Firebird also forces Windows to flush its cache regularly, which should be a boon for our Latin American users.
Best regards,
Ann
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
