>>Can you tell me how _TALLY is supposed to follow a sql-select?
>
>I don't do that as a matter of course myself, but I'm now considering doing so after it was mentioned.
>As you know, _TALLY tells you how many records were selected (or affected in the case of other commands). As you also know, _TALLY will be changed the next time any "table command" is executed.
>When you select INTO an array or TO anything you have no other practical and safe way of knowing how many records were affected/created other than by inspecting _TALLY. Particularly relevant for INTO array because there will be no array if no records were selected. Keeping the returned _TALLY value in a memvar is a smart thing to do. In fact I can argue that it simplifies maintenance because you can change your destination with less impact on other code.

select somefield1 from table1 into array laResult

if _tally > 0
   for ln = 1 to alen( laResult, 1 )
      ? laResult[ ln, 1 ]
   next
endif

This construction is necessary indeed in case of an array. But it is less necessary in case the result is put in a cursor or table, because that thing will be created anyway, even if there are no records in it. All intermediate and advanced professionals should know this default behavior of the sql-select. Ergo, the usage of _tally in the next example is overdone.

select somefield1 from table1 into cursor c_result

if _tally > 0
   scan
      ? somefield1
   endscan
endif

>>>Do you also get upset with assigning LOCAL-defined variables with .F. at the beginning of a program?
>>>If so, then I'd say you do let the wrong things bother you.
>>
>>As a matter of fact, declaring them anyway is preferable indeed. It indicates that the developer has not forgotten their declaration.
>
>Ah, but you contradict yourself because all locals DEFAULT to .F. So what we have is discretionary "standards". Funny, but that's what I'm talking about too.

See my reply to Rich Pupko.