Subject | Re: [IBO] IBOQuery performance issue with Key select |
---|---|
Author | Aurimas Černius |
Post date | 2008-11-25T12:50:11Z |
Hello,
I have a grid, that displays data and user can sort and filter it by any
column. So, WHERE part in select statement usually varies very much.
It's not like NAME=:NAME, it can (and in fact does) change to almost
anything, that's possible in SQL.
I hardly see a way to use parameterized query here.
different (where and order by parts that differ as I told before) almost
every time.
I don't need things like "insert in place" as grid is read-only and user
has a separate window to insert/edit record.
What is this operating between app and server's buffer?
So, IBO is such by design and I can't change the way it performs statement?
* is really what I need. And unfortunately I don't see way to have WHERE
with parameter.
Maybe switching to some lightweight interface like UIB is really what I
need and IBO was a bad choice?
--
Aurimas
> >I've a problem, that greatly reduces performance of select usingWell, that's exactly what I do...
> >IBOQuery. The problem is with wome internal stuff of IBOQuery
> >implementation.
> >
> >When I pass a select statement to query, it apears (using IB_Monitor),
> >that it first selects key fields, specified in KeyLinks property or
> >RDB$DB_KEY, if none are specified. Only then it selects real data.
> >What I see is that all this extra stuff is much slower, than the select
> >itself.
> >
> >Results of my tests:
> >When KeyLinks is empty: 6+ sec.
> >When KeyLinks are set: 4.5 sec.
> >
> >If i use a Query component from UIB components, the same select
> >statement is executed in about 0.75 sec., so its a huge difference
> >compared to IBO. Unfortunately, I have hundreds of lines of written and
> >tested code, so switching to other components is painful.
> >
> >Is there any way to change the behaviour of IBOQuery, so that it would
> >just execute the statement and not do all those "smart" things? Or any
> >other suggestions?
>
> Always set KeyLinks and always use parameterised queries. Avoid
> constructing static queries in run-time.
I have a grid, that displays data and user can sort and filter it by any
column. So, WHERE part in select statement usually varies very much.
It's not like NAME=:NAME, it can (and in fact does) change to almost
anything, that's possible in SQL.
I hardly see a way to use parameterized query here.
> If you do this in the proper client/server way, the Keyfields[] arrayCurrently I make entire statement from scratch every time, because its
> will make successive runs of this query much faster. It is also
> important in the implementation of the buffering mechanism that IBO
> operates between your app and the waiting rows in the server's buffer,
> something that lightly implemented interfaces like UIB don't support.
> Amongst other things, it gives you "insert in place", which for users is
> highly preferable to Append.
different (where and order by parts that differ as I told before) almost
every time.
I don't need things like "insert in place" as grid is read-only and user
has a separate window to insert/edit record.
What is this operating between app and server's buffer?
So, IBO is such by design and I can't change the way it performs statement?
> Don't run select * queries unless you really *want* all of the columnsFor displaying data in grid I usually need almost all columns, so select
> of a table; and always use a WHERE clause, with parameters.
* is really what I need. And unfortunately I don't see way to have WHERE
with parameter.
Maybe switching to some lightweight interface like UIB is really what I
need and IBO was a bad choice?
--
Aurimas