Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 9 of 9 total |
Is there any speed improvement in using TEDBTable over TEDBQuery? |
Thu, Nov 15 2012 12:16 PM | Permanent Link |
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? TIA Barry |
Fri, Nov 16 2012 4:44 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Sat, Nov 17 2012 1:06 PM | Permanent Link |
Barry | 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 |
Sun, Nov 18 2012 4:10 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Mon, Nov 19 2012 11:26 AM | Permanent Link |
Barry | 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 |
Mon, Nov 19 2012 11:51 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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] |
Mon, Nov 19 2012 2:11 PM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | 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 |
Mon, Nov 19 2012 3:32 PM | Permanent Link |
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, 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 |
Wed, Jan 2 2013 6:12 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |