Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 19 of 19 total |
filtering tables takes |
Wed, May 14 2008 3:58 PM | Permanent Link |
"Robert" | "Santy Concepción" <santyweb@hotmail.com> wrote in message news:338A13E1-4982-44D6-A605-1BB480D74112@news.elevatesoft.com... > Hi Tim and Roy. > > LAN speed is 54Mbps (wireless). > Using SQL Query it is very very fast (less than a second to show results), > but using table filter it takes about 15 seconds to filter the table. > > The problem is that, using the "Set an Expression Filter" of DBISAm System > Utility, it only takes ONE second to show the records!!! > Why my application takes so long if I'm only doing the same? Hint: you are not doing the same. The data is different, or you are using a different version of DBISAM. "The data is different" might have something to do with the active index on the table. Maybe if the field you use in the filter is also the active index, the filtering process can be much faster. I don't know for sure, but worth exploring. Set the active index the same on your program and on DBSYS, and try to apply the filter. Robert |
Thu, May 15 2008 2:24 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Santy
If it works fast in DBSys (just an app using DBISAM remember) and slow in your app it suggests one of two things is happening: 1. you're pointing at different data 2. your app is doing some processing or is linked to other controls which is slowing the process down. If its not the former you can either build a very simple app and keep adding stuff until it slows down or take your existing app and keep removing stuff until it speeds up - look for events, linked controls etc. Roy Lambert [Team Elevate] |
Thu, May 15 2008 4:53 AM | Permanent Link |
=?iso-8859-1?Q?Santy_Concepci=F3n?= | This is the problem:
I have two copies of DBISAM System Utility, one on "\Util\Dbsys" and another on "\UtilS\Dbsys" (don't know why). One of them is compiled with 4.25 Build 1. It is awesome fast and takes only a second to apply the filter. The other one is compiled with 4.26 Build 2, and it takes about 15 seconds to show the results. Table is the same, path is the same, application is the same and filter is the same. There is something different in latest release. "Roy Lambert" <roy.lambert@skynet.co.uk> escribió en el mensaje de noticias:E29939C3-78D9-4E72-B6FF-2F01B1755626@news.elevatesoft.com... > Santy > > > If it works fast in DBSys (just an app using DBISAM remember) and slow in > your app it suggests one of two things is happening: > > 1. you're pointing at different data > 2. your app is doing some processing or is linked to other controls which > is slowing the process down. > > If its not the former you can either build a very simple app and keep > adding stuff until it slows down or take your existing app and keep > removing stuff until it speeds up - look for events, linked controls etc. > > > Roy Lambert [Team Elevate] > > |
Thu, May 15 2008 6:09 AM | Permanent Link |
"Jose Eduardo Helminsky" | Santy
There is a known bug in 4.26 that can affecting your results. Eduardo |
Thu, May 15 2008 7:27 AM | Permanent Link |
=?iso-8859-1?Q?Santy_Concepci=F3n?= | Thanks, Eduardo. I was getting crazy.
Is it possible to fix this in the next release, please? "Jose Eduardo Helminsky" <contato@hpro.com.br> escribió en el mensaje de noticias:257AF8C3-C00A-4D7E-A6F2-093981E889C1@news.elevatesoft.com... > Santy > > There is a known bug in 4.26 that can affecting your results. > > Eduardo > > |
Thu, May 15 2008 2:20 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << The expression: upper(MOV) = upper('COMPRA') and FECHA BETWEEN '2008-01-01' AND '2008-02-01' has been rewritten and is PARTIALLY-OPTIMIZED, covers 0 rows or index keys, costs 0 bytes, and will be applied to the movim table (movim) before any joins >> This is the issue - 4.26 B2 has a bug in it whereby expressions are not being rewritten properly by the query optimizer. A fix will be available within the next week. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 15 2008 5:38 PM | Permanent Link |
=?iso-8859-1?Q?Luis_Concepci=F3n?= | Thank you, Tim. I will wait for it.
Please remember that I'm using table filters, not queries. "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> escribió en el mensaje de noticias:C0987E9D-D1E7-4DEF-93B0-0169734F16FA@news.elevatesoft.com... > > << The expression: > > upper(MOV) = upper('COMPRA') and FECHA BETWEEN '2008-01-01' AND > '2008-02-01' > > has been rewritten and is PARTIALLY-OPTIMIZED, covers 0 rows or index > keys, > costs 0 bytes, and will be applied to the movim table (movim) before any > joins >> > > This is the issue - 4.26 B2 has a bug in it whereby expressions are not > being rewritten properly by the query optimizer. A fix will be available > within the next week. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Fri, May 16 2008 12:43 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Luis,
<< Thank you, Tim. I will wait for it. Please remember that I'm using table filters, not queries. >> Query conditions are materialized through filters, so this situation applies to both. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, May 18 2008 9:50 PM | Permanent Link |
Sean McCall | This may be a bit late to the game, but it can take longer to display
the results of a table filter when there are no matching records or very few matching records because the entire table has to be scanned until EOF or there are enough records to fill the TDataset buffer. I believe that the buffer is the size of the largest number of visible rows in any attached grid or 1 if only attached to data aware controls. Sean Santy Concepción wrote: > Hi! > > I have been trying to improove the speed of my app on a LAN (not C/S), > using latest DBISAM 4 release and Delphi7 Pro. > I'm playing with table filters to see which conditions order is the best. > > I have noticed that changing the condition values of a DATE filter > condition takes more or less time to execute depending on the number of > records to show, BUT only takes more time when there are no matching > records! Is it correct? > > For example... > > upper(MOV) = upper('BUY') and DATE >= '2007-04-01' and DATE <= > '2008-05-01' > > ...takes 0,3 seconds to show the results (about 60 records) > > However... > > upper(MOV = upper('BUY') and DATE >= '2008-01-01' and DATE <= > '2008-02-01' > > ...takes 16,0 seconds to show the results (0 RECORDS!!) > > Why the second filter, which has no matching records, takes more time to > show? > Is it possible to optimize it? (Table contains indexes for MOV and DATE > fields) > > Thanks! > > |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Thursday, March 28, 2024 at 08:36 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |