Hi Garrett,

yes, i try to explain my point of view.

On VFP various Character string comparison rules exists.

Fundamental elements of this are:
1. string expressions
2. blank character
3. == Operator
4. = Operator
5. SET EXACT ON/OFF
6. SET ANSI ON/OFF
7. order of comparison members
8. context where comparison is done.
9. COLLATE setting

For for this analysis, point 9. is not important.

Split point 8.: context:

I) Focus attention on SELECT ... WHERE command.
Points 5. and 7., they does not have affect on result.
On this i can use:

a) == for ANSI SQL-92 standard comparison: trailing blanks is ignored
b) = with SET ANSI ON : is identical to a)
c) = with SET ANSI OFF : strings are equal if one corresponds to the beginning of the other ( blank is a character like other ).

II) Focus attention on cursor control commands (SCAN.. REPLACE .. ) WHILE and
FOR clauses.
Point 6. it does not have affect on result
On this i can use:

a) ==  precise comparison: two strings they must be identical ( blank is a character like other ); point 7. does not have affect on result.
b) = with SET EXACT ON : this is identical to point I)a) comparison rule;    point 7. does not have affect on result.
c) = with SET EXACT OFF : strings are equal if right string corresponds to the beginning of the left string ( blank is a character like other ).
This is similar to I)c) with Point 7. restriction.

For point I) and II), any result not change if VFP use indexs or not use indexs.

Until this point I have 3 comparison rule to remember:
- I)a) I)b) II)b)
- I)c) II)c with point 7. restriction
- II)a)

III) Focus attention on direct index command (KEYMATCH SEEK SEEK() ... )
Point 6. it does not have affect on result
Problem:
- not exist a explicit operator: = or ==
- not exist a explicit order of comparison member
Then, I must go for deduction:
Because these commands are sensitive to SET EXACT they use =
Because for SET EXACT OFF these command use this order:
sKeyString = sKeySearched
the searched string is the right member.
Then:

a) with SET EXACT OFF the seek use II)c) comparison rule with sKeySearched like right member.
b) with SET EXACT ON the seek use another comparison rule:
if LEN(sKeySearched)<LEN(sKeyString) then use II)b) comparison rule,
else comparison not match ( like II)c) comparison rule )

The III)b) comparison rule is different to any comparison rule on I) and II) contexts.

The result is this:
i cannot replay comparison I)a) and II)b) with direct Seeking command.

If i developer code with I) or II) commands and next optimize it with seeking command, for SET EXACT OFF or SET ANSI OFF i can write similar expression,
but with SET EXACT ON or SET ANSI ON i need remember III)b) point
and seeking RTRIM(sKeySearched) to maintain the same operation.

A simple and classic optimization example:

INDEX ON cField TAG tag1
SET EXACT ON
* next code is not correct
SEEK m.sKeySearched  && use III)b)
SCAN WHILE cField=m.sKeySearched && use II)b)
...
ENDSCAN
* workaround corection
SEEK RTRIM(m.sKeySearched)  && use III)b) but now it is like II)b)
SCAN WHILE cField=m.sKeySearched && use II)b)
...
ENDSCAN

NOTE: My English is uncertain, but I hope to me it are explained.

Garrett, if you can, forwards this to the high plans.

Fabio