> > 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 ?

Yes, this is the best component to use for batch inserts.

> > 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

?

You are safe with InterBase. The only reason you want forced writes on is if
you SERVER is ever susceptible to a power failure or your OS install is in
flaky condition.

What I usually do is leave forced writes on and when I am doing some hard
crunching in a batch job I turn them off temporarily and put them back on
again when I am done. I usually always have a backup prior to doing major
crunch updates/loads to my database in case something does go wrong.

A failed client will not adversely affect the server's data integrity,
period. That's client server.

> > 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.

Get over it!

> > 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 behavior 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.

IB will be slower than paradox if you are not taking advantage of any of the
additional features and capabilities that InterBase has. With hardware ever
increasing I really don't think this is a significant performance gap.
InterBase is so efficient that it can and will do a good job in a single
user environment.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com