I have a Delphi form with a parent grid and two child grids. When the parent grid row moves to a different row, the child grids will display rows for the new parent row. It is using the classic Master Source scenario when setting up the data sources, with indexes of course.

Would it be any faster if I replace the child dataset with a TEDBTable instead of a TEDBQuery? Or is the TEDBTable emulating a TEDBQuery?

TIA
Barry

Barry

>I have a Delphi form with a parent grid and two child grids. When the parent grid row moves to a different row, the child grids will display rows for the new parent row. It is using the classic Master Source scenario when setting up the data sources, with indexes of course.
>
>Would it be any faster if I replace the child dataset with a TEDBTable instead of a TEDBQuery? Or is the TEDBTable emulating a TEDBQuery?

Partly the answer to that depends on how things are set up. In C/S a query should be faster since less data will be transfered in F/S I have generally found that a table feels faster but I've never done any timings to prove it one way or the other.

Roy Lambert [Team Elevate]

Roy Lambert wrote:

>Partly the answer to that depends on how things are set up. In C/S a query should be faster since less data will be transfered in F/S I have generally found that a table feels faster but I've never done any timings to prove it one way or the other.
<

In C/S I would have thought the server would return only those child TEDBTable rows that satisfies the index filter/range. I also assumed unindexed filters would have the work done on the server and only those rows that satisfies the filter would be sent to the client.

I know with other F/S databases (dbISAM and Nexdb), tables that use ranges are considerably faster than queries, especially when sorting is required.

I don't have tables large enough to do any comparison between TEDBTable and TEDBQuery. I guess that will have to wait for another day.

Barry

Barry

>I know with other F/S databases (dbISAM and Nexdb), tables that use ranges are considerably faster than queries, especially when sorting is required.

Yes I remember Tim posting that now you've mentioned it.

>I don't have tables large enough to do any comparison between TEDBTable and TEDBQuery. I guess that will have to wait for another day.

How big a table would you need to test?

Roy Lambert [Team Elevate]

Roy Lambert wrote:

>>I don't have tables large enough to do any comparison between TEDBTable and TEDBQuery. I guess that will have to wait for another day.

>How big a table would you need to test?

This is a theoretical question, so how high is high? VBG

I was wondering if it is more efficient to use TEDBTable for child grids as a standard when I am designing my forms, or are TEDBTable's really emulating a TEDBQuery and I'm just wasting my time going with EDBTable?

Barry

Barry

>>>I don't have tables large enough to do any comparison between TEDBTable and TEDBQuery. I guess that will have to wait for another day.
>
>>How big a table would you need to test?
>
>This is a theoretical question, so how high is high? VBG

You obviously have a lower limit or you wouldn't be able to say your's are too small. <vbg>

>I was wondering if it is more efficient to use TEDBTable for child grids as a standard when I am designing my forms, or are TEDBTable's really emulating a TEDBQuery and I'm just wasting my time going with EDBTable?

If the lookup tables aren't too big, and don't change too often then replicate them locally (possibly in memory) and get the fastest solution.

Roy Lambert [Team Elevate]

Barry

*ALWAYS* acessing tables will be faster than queries. Queries, in the
background, open the tables, check their indexes and build an array of
record pointers or create a temporary table to work with.

In the master/detail scenarium, the best aproach is handle
Datasource.OnDataChange event and apply a range in the child table. I can
guarantee it is faster than prepare a query (specially if it will be
canned). And remember, if child table has thousands of records only the
records that appear in the grid will come from server, it will happen page
by page.

Eduardo

>>*ALWAYS* acessing tables will be faster than queries. Queries, in the
background, open the tables, check their indexes and build an array of
record pointers or create a temporary table to work with.

In the master/detail scenarium, the best aproach is handle
Datasource.OnDataChange event and apply a range in the child table. I can
guarantee it is faster than prepare a query (specially if it will be
canned). And remember, if child table has thousands of records only the
records that appear in the grid will come from server, it will happen page
by page.<<

Eduardo,

Thanks for the confirmation. I wasn't sure if EDB implemented TEDBTable as a true table with Ranges, or emulated it as a TEDBQuery. (I don't have the source code).

So if the child tables don't have (many) lookups, I'll use TEDBTables with Ranges instead of TEDBQuery.
(Or as Roy suggested, if there are lookups, cache the lookup data in a local table).

Thanks
Barry

Barry,

<< I was wondering if it is more efficient to use TEDBTable for child grids
as a standard when I am designing my forms, or are TEDBTable's really
emulating a TEDBQuery and I'm just wasting my time going with EDBTable? >>

No, TEDBTable does not emulate a TEDBQuery.  It's its own table cursor that
can do filtering, etc. in a very efficient manner, even over a WAN.  EDB
only every fetches the RemoteReadSize number of rows (or the max visible
number of rows in a connected grid/multi-line control), even if there are
millions of rows in the table.  And, FindKey, SetRange, etc. are all very,
very fast.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com