At 07:35 AM 08-01-01 -0600, you wrote:

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

He is using the TIBO* components.

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

It depends.
With a proper Client/server setup (remote client interface) the server
won't be affected by crashing clients. With a local connection (this
inquirer's scenario) it could be.

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

Possibly true, but it is totally invalid for benchmarking. There is
nothing about this that is helpful in evaluating relative performance.

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

1. Using Table components for bulk inserts.
2. Not understanding the difference between Post and Commit. (Default BDE
behaviour is to hide the transaction and commit the transaction every time
a dataset calls Post. Hence, no way to put a group of work into a
transaction; and all datasets get closed and opened every time any dataset
calls Post. This is pretty typical of those who never used a C/S database
before, or who used IB under the BDE and never accessed the embedded
transaction explicitly).
3. Not using Params, or using them wrongly. A common error is to turgidly
construct SQL statements by concatenating pieces of SQL with literal values
read from controls. Thus, the dataset has to be prepared each time it is
opened. With Params used properly, Prepare is only called the first
time. (Exception is executable SPs - they have to be prepared every time
because of a bug in InterBase).
....
....
n. Here endeth contents of forthcoming book "Programming InterBase with
Delphi". <g>

Actually, there is a tech info sheet coming up soon, "The Client/Server
Mindshift".

H.



All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________