At 02:42 PM 27/06/2003 +1000, Peter McLeod wrote:

>Referring back to your earlier advice the application that I am porting,
>doesn't
>have a gazillion active datasets. Most datasets are created dynamically and
>then destroyed when fished, in order to reduce network traffic and conserve
>system resources.

This is by no means a good rule for optimal performance with IB unless a
dataset is wanted only once in the session. The problem with this
technique is that you waste both server resources and increase network
traffic by preparing the statement every time it is used.

>Where ever possible I try and use appropriate client server
>design techniques (For instance refer to my article on Delphi 3000. Improve
>Interbase Client Server Performance. I can't always do this as sometimes the
>Boss, prefers things done in a different fashion, but this is not the case
>here).
>In any instance, I would still imagine that IBO would be faster than BDE
>as IBO
>talks direct to the underlying API to achieve it's result.
>
>I also performed the test locally, and found that the BDE was faster than
>IBO.
>Do you have any other suggestions for things to look at?

Having read your article, I would guess that there are probably a lot of
things to look at. Perhaps a good starting place would be the TechInfo
papers, esp. those on transactions. If you *believe* the stuff in your
article about IB indexes, then I'd suspect that you have some problem
indexing to deal with. If you are using Autocommit, then you need to look
at its implications for database performance; and you need to get hold of
some better "facts" about garbage collection.

Also, I think you would gain a benefit by rethinking your views about
triggers and stored procedures. It's just not true that they cause
bottlenecks on the server! Some people do avoid them because they want
their applications to be portable to a number of different RDBMSs. They do
that at the cost of performance and integrity. In fact, the importance of
enforcing business rules in one and only one place wasn't mentioned in your
article at all.

Anyway, if you are considering moving from the BDE to IBO, then I assume
it's not a vendor-neutral database interface that you are trying to achieve..

It would be a worthwhile exercise to get inside some of the sample apps
that installed with IBO. At least, I uncovered a lot of my own wrong
assumptions when I first worked through those projects...

Helen