Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 19 of 19 total
Thread filtering tables takes
Wed, May 14 2008 3:58 PMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 AMPermanent 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 AMPermanent 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 PagePage 2 of 2
Jump to Page:  1 2
Image