>>Other than VfP has a serious fault with querying ???
>>
>>I don't know if you read earlier messages, but this fault was evident as far back as Foxpro 2.6, both DOS & Windows. It was reported to MS, but treated as a non-problem - so 5 years on the fault is still there.
>
>I thought about this some more yesterday. I think what's going on is that VFP has a higher standard of match for a join condition (and any condition involving more than one table is a join condition) than for a filter. That would explain what you're seeing. It would also explain why this has never been a big issue - most people do their joins on some kind of key field, so would never run into this situation.
>
>I'll reserve judgment on whether the behavior is right or wrong. For me, the first step is to understand what's happening.
>
>Tamar

Despite having used Foxpro & VfP to some extent for over 5 years, it has only been for peripheral things to the main applications, so I hope you will forgive what may be a stupid statement.

In my example, the key fields were the fld1b & fld2b fields, or so I thought. The choice of names & lack of indexes was solely to reduce the complexity of the examples, the problem exists regardless. My example closely followed those given in the documentation for select-sql, so I assumed I was working along the right lines.

What is most disturbing though, is the different result sets generated between example 2 & 3 - where only the order of the expressions in the query affect the result.

Again it may be more ignorance (it was almost those exact words used by the MS support person 5 years ago, BTW), but it does seem to me that the VfP native SQL does have severe faults.