>Just encountered a bug in our software releated to the use of = when set exact is set to off.
>
>I Know I should be using == in those cases where comparing strings of different lenght, but just a small test made me wonder.
>
>Is there any reason I should not use == for any comparison in VFP? It seems to work for any datatype.
>
>Is there any gotcha using == as a standard?

The gotchas I know of are kind of obsolete:

- when comparing datetimes, where one is coming from a table and one a variable assigned a datetime(), one of them may contain milliseconds and the other not; used to be a problem in VFP 5 or 6, then datetimes lost the milliseconds. That is the format still supports them, but is not stored. They are now always rounded to whole seconds. Still you may hit a table written with one of these older versions and hit those hidden milliseconds (they were never displayed, but you could subtract two seemingly identical datetimes and get a number between -1 and 1).

- comparing floating numbers is unreliable; it actually works but not as expected. Display value of a number is rounded to set("decimals") or whatever way it is formatted; internally it's an IEEE number with 15.5 significant digits. So 7.99...98 may not be equal to 8.0...001 even though both may display as 8.00.

- in collating sequences other than machine, uppercase equals lowercase in ordinary comparison but not in ==
SET COLLATE TO "MACHINE"
?"A"="a", "A"=="a"
SET COLLATE TO "GENERAL"
?"A"="a", "A"=="a"
also some character combinations may be treated as equal when they are not or you may get some weird ordering:
SET COLLATE TO "czech"
?"ch">"c"

That's pretty much all the weird cases I can remember.