Tim,

I am filling a tree component with data, which requires lots of small ranges/queries.

1. Which component would you recommend for that, EDBQuery or EDBTable?

2. Which one has a more low level way of working with data? For example, when a Range is
applied via SetRange, is it translated into an SQL statement during execution?

3. Does EDBTable have any speed advantage over EDBQuery? If yes, in what cases and how much?

Regards,
Leslie

Leslie,

<< 1. Which component would you recommend for that, EDBQuery or EDBTable?
>>

It really is up to you.  We use simple queries with sensitive result sets in
the ElevateDB Manager for this, and it works great, provided that you do
"on-demand" loading of the treeview nodes.  Unless you are particularly
sensitive about the performance due to project requirements, you probably
won't notice the difference between the two in terms of UI response.  Of
course, that depends upon how complicated the queries are, but simple
queries that return sensitive result sets will perform approximately as fast
as a direct range or filter on a table.

<<2. Which one has a more low level way of working with data? >>

The navigational methods, SetRange, FindKey, etc. are all more direct than
SQL.

<< For example, when a Range is applied via SetRange, is it translated into
an SQL statement during execution? >>

No, it is always executed directly using native code.

<< 3. Does EDBTable have any speed advantage over EDBQuery? If yes, in what
cases and how much? >>

It really depends upon what you're doing.  Sometimes it pays to use a
TEDBTable, while other times it is much more efficient to use the TEDBQuery
component instead.

--
Tim Young
Elevate Software
www.elevatesoft.com

Leslie


In a DBISAM app I used a table in the outside loop and then queries and I'll be porting that over - I just found it easier with the recursive calls to the function to create children of children of children etc.

The thing I found helped the most in terms of speed was to use BeginUpdate / EndUpdate and to make sure that there was as little UI involvement as possible whilst doing the population.

Roy Lambert

Thank you Roy!

Tim,

Such diffrences only matter when there are many records in the table. Looks like I cannot
escape from testing once again.


Thank you for your answer,
Leslie

Leslie,

<< Such diffrences only matter when there are many records in the table.
Looks like I cannot escape from testing once again. >>

Well, ranges and direct key searches (FindKey) all operate pretty much
independently from the row count for the table since they always use
indexes.

--
Tim Young
Elevate Software
www.elevatesoft.com