I agree with your statement. Any function you toss into your index has to
be run row by row to evaluate the correct value. This is not optimizable
because the data is being tweaked. Using INTs as keys saves you from this
nightmare.
On Tue, Mar 20, 2018 at 1:22 AM, Fernando D. Bozzo
Using ALLTRIM() on idexes is a bad idea, the full field is always better
and faster, because VFP does not have to preprocess the value for
searching, for adding a new value and for reindexing.
El lun., 19 de marzo de 2018 23:29, Bill Anderson
escribió:
> Mike,
>
> I
On 2018-03-19 18:29, Bill Anderson wrote:
Mike,
I believe ALLTRIM()s in SQL doesn't "defeat" optimization, it's just
that
you can't have ragged (meaning, varying length) indexes in VFP.
A tag on ALLTRIM(field) is padded out to the full length of the field.
Bill Anderson
Hi Bill!
But it
Mike,
I believe ALLTRIM()s in SQL doesn't "defeat" optimization, it's just that
you can't have ragged (meaning, varying length) indexes in VFP.
A tag on ALLTRIM(field) is padded out to the full length of the field.
Bill Anderson
On Mon, Mar 19, 2018 at 12:55 PM, <
-Original Message-
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of
mbsoftwaresoluti...@mbsoftwaresolutions.com
Sent: Sunday, March 18, 2018 2:34 PM
To: ProFox
Subject: Testing tells the tale (SYS 3054) -- "BETWEEN(a,b,c)"
equivalent to "a BETWEEN b and c"
I was working at a place that did ran batch processes at night using VFP. One
of the managers came up to me and told me of a process that used to take 30
minutes now was taking 5 hours. Combined with the other processes, this meant
we couldn't complete the processing overnight any longer and
6 matches
Mail list logo