>>>Count(*) is supposed to start counting on each group. In this case there is no group, so it counts all the way to the end of the table, resulting in a count(*) of the number of records in the table which is certainly >1. The having takes place after returning the set of records indicated by select key from mytable. So VFP is physically sitting on the last record when the having count(*)>1 condition evaluates to .T. and so you get the last record.
>>
>>Mike,
>>
>>OK, thanks for the explanation. I was going too fast editing a prior line in the command window, and I left out the GROUP BY 1 part. I was surprised when I got a record returned. As it happens, for this legacy app I am in VFP7, but I had no guess as to why it happened.
>
>It's been so since FP 2.0 - if you have an aggregate function and don't include a group by, you get a grouping on the whole result, and one record as a result. The only thing that's changed is that if the where clause returns no records, up to VFP6 you get no records, while in VFP8 and 9 you get one record with nulls. Not exactly sure where 7 stands on this. I did one conversion from 6 to a newer version, and that was one thing I had to check across the system, but it always had select ... into array, and I had to check for nulls in the array instead of checking _tally, because _tally was now 1 regardless of the outcome.

OK, thanks, Dragan

Al Allison