At 06:18 PM 9/03/2003 -0800, you wrote:

>I had an issue with IBO causing the database to corrupt.

IBO can't cause the database to corrupt. It's an interface to the client
library and the client library, per se, can't cause the database to
corrupt, either.

However, you (the developer) or your sysdba can cause the database to
corrupt. This can be by...
* not taking care of the connection string bug (if the database isn't
Firebird).
* not unpreparing DML statements between executions (again, only a problem
in InterBase 5 & 6).
* trying to run multiple instances of a local connection - something that
hasn't been safe to do since IB 4.1.
* trying to multi-thread a local connection
* shutting down or powering off the server power whilst a sweep or gbak is
running
* running filesystem backup, copy or compression whilst the server is
active (worse if done during gbak or sweep)
* using the wrong gds32.dll

>We fixed it by forcing all transactions in our exe to commit and closing
>the IBConnection when closing the app.

Provided your application shuts down normally, IBO will finalize it by
doing exactly that. But, even with an abend, uncommitted transactions
don't cause corruption...

You can get bad data (i.e. non-structural data corruption) with IBO (or any
SQL interface) by using unqualified identifiers in multi-table query
specifications. An ambiguous select in itself doesn't hurt anything; but
if you are performing DML operations based on the contents of output from
an ambiguous query then anything can happen. This is an InterBase-only
issue, as well, since any multi-table query in Firebird will simply throw
an exception if you don't include qualifiers.

Helen