Helen,

> 1. If it's performance you are seeking, there is NO WAY you should be
> using TIBOTable for an executable process. Put this statement into a
> TIBOQuery...

Would a TIB_DSQL component not perform better for bulk inserts since it does
not have the extra baggage associated with the TIBOQuery component ?

> 3. Forced writes will slow things down (as observed) but if you have a
> fragile network environment or users who habitually terminate a database
> session by switching the computer off, it's worth the cost.

Really ? I have client sites where the users habitually terminate a database
session by switching the computer off. I have been trying to break them of
this habit for years, but without success. I was under the impression that
IB would solve this problem due to it's C/S design. What kind of problems
can I expect when this happens ? I realize that any pending transactions
will not be committed, but please tell me my database will still be intact ?

> As a general comment, it doesn't make sense to force InterBase to behave
> like a file-based database (which it's not) and then expect it to compare
> favourably with file-based databases, performance-wise. The kind of
> "benchmark" you are trying to do is rather silly, for example, because one
> would never be inserting 1000 records from a table interface. The Insert
> and Append methods are intended for one-by-one manual inserts.

I agree that this is a silly test, but it is probably one of the first tests
that every BDE to IB convert tries. The table interface gives the developer
the warm fuzzies they had with the BDE TTable component and is a natural
selection.

> A further comment is this. Client/Server databases aren't intended for
> desktop use. If speed is your only criterion then stay with the desktop
> database. The transaction model is meant to preserve data integrity in a
> multi-user environment. It would be surprising if there were no cost to
> that. If your single-user app is getting broken by user behaviour under
> Paradox, it won't get better by switching to another database.

I would imagine that the majority of people migrating from Paradox to IB are
switching for the improved multi-user support, but still need to support a
single user environment. I have found that IB performs quite well in a
single user environment as long as the app and database are designed to take
advantage of IB's strengths. Reads, inserts and updates all appear to be
much faster. Could you elaborate on where IB might be slower ? This could be
very helpful to newcomers like myself.

Thanks,

Chris Landowski
Dynamic Software Solutions