> I have run into this interesting problem recently that if I try to find a
> record with query that looks like :
[quoted text clipped - 10 lines]
>
> Provider=vfpoledb.1;Collating Sequence=general;Data Source=C:\DATABASE\
Hopefully someone that truly 'knows' will come in here and make it clearer.
But the explanation that I have always been given is because the Like
Statement does a simple text comparison, skips the 'optimizer', and thus
allows a quick bail (short-circuit). Just marches down the file pulling
whatever "fits".
However, this phenomena is confined mostly to ISAM databases or those with
ISAM roots or binary text compare'ers (eg, Jet). And of course depends on
the data type. In dbf files everything is ASCII (text).
hth
-ralph
Hi Darrell,
I haven't tested but you may be interested in what the VFP Help says about
the ANSI setting for SQL queries. You can change the ANSI setting by issuing
SET ANSI ON or OFF.
Visual FoxPro 9.0 Language Reference
SET ANSI Command
In the Visual FoxPro OLE DB Provider, you cannot query the value of
ANSI using the SET command though SET ANSI is supported.
SET ANSI ON | OFF
Specifies whether to pad a shorter string with spaces when making a SQL
string comparison or binary expression with zero (0) bytes when making a
binary expression comparison in SQL commands using the equal sign operator
(=).
Note
In the Visual FoxPro OLE DB Provider, you cannot query the value of
ANSI using the SET command though SET ANSI is supported.
SET ANSI ON | OFF
Parameters
ON
Pads the shorter string or binary expression with spaces or zero (0) bytes
needed, respectively, to make it equal to the length of the longer string or
expression. When SET ANSI is set to ON, the two strings or expressions are
compared character for character for their entire lengths.
OFF
Specifies that the shorter string not be padded with spaces or binary
expression not be padded with zero (0) bytes. (Default)
When SET ANSI is set to OFF, the two strings are compared character for
character until the end of the shorter string is reached.
Remarks
SET ANSI has no effect on the double equal sign (==) operator. When you use
the == operator, the shorter string or binary expression is always padded
with spaces or zero (0) bytes, respectively, for the comparison. For more
information, see Relational Operators.
.......
String Order In SQL commands, the left-to-right order of the two strings
in a comparison is irrelevant - switching a string from one side of the = or
== operator to the other doesn't affect the result of the comparison.
<<
Also, you should know that the FoxPro Rushmore technology will speed up
queries when the expression in the Where or Join clauses exactly matches the
expression in an index on the table.

Signature
Cindy Winegarden MCSD, Microsoft Most Valuable Professional
cindy@cindywinegarden.com
VFP OLE DB: http://msdn2.microsoft.com/en-us/vfoxpro/bb190232.aspx
VFP ODBC: http://msdn2.microsoft.com/en-us/vfoxpro/bb190233.aspx
>I have run into this interesting problem recently that if I try to find a
> record with query that looks like :
[quoted text clipped - 10 lines]
>
> Provider=vfpoledb.1;Collating Sequence=general;Data Source=C:\DATABASE\
Darrell Wesley - 29 Jan 2007 14:18 GMT
This field is indexed not a primary key index but a regular index.
It should have been set as a primary key by the person who created it but it
wasn't and now I find that there are records with duplicate values in this
field. Don't know if that may be the cause of the slow responce or not.
> Hi Darrell,
>
[quoted text clipped - 66 lines]
> >
> > Provider=vfpoledb.1;Collating Sequence=general;Data Source=C:\DATABASE\
Ralph - 29 Jan 2007 17:33 GMT
> This field is indexed not a primary key index but a regular index.
>
[quoted text clipped - 3 lines]
>
> > > <snipped>
It certainly wouldn't help. <g>