>>>Is this still true?
>>>
>>>oldvalue = ""
>>>value = "anystring"
>>>
>>>oldvalue = value (returns .T.)
>>>
>>>I thought this problem was fixed long ago, but I just ran across a situation where it appears the problem was not fixed.
>>>
>>>I SET EXACT ON still the cure?
>>>
>>>regards,
>>
>>It's always considered as a feature (not bug) and SET EXACT (SET ANSI for Select-SQL) should still care about it.
>
>Hi Edward,
>
>There, now you see how far behind the times I am. Since I could never figure out any conceivable use for this "feature", I alway thought it was a "bug". Foolish me!
>
>A couple of weeks ago I was reading in the MS KB about how to test if a combobox value had been keyed-in rather than selected, and the code specified comparing ".displayvalue != .value". I tried that and it does not work where either .displayvalue or .value is blank. Someone at MS needs to learn about this "feature".
>
>So ("feature" # "bug") = .T. I get it now.
>
>Glad to see the old tried and true workarounds still work.
>
>regards,

I used to SET EXACT ON at start of any application. Anytime I reread 'String Comparison' article from Help, it drives me crazy for years :).