Now I understand why some people mentioned a connection between _tally and Set("TALK").
I've ported one routine from FPD2.6 into a method; it calls another routine which copies some records into a r/w cursor, indexes the cursor, and then, if _tally#0, calls a grid to display the results. Worked so for years.

No luck - it never shows the grid. After extensive debugging (i.e. two coffees), I've found that the cursor gets created, it gets indexed, and _tally is always 0. Here's what Help says;

[Quote]
_TALLY System Variable

Contains the number of records processed by the most recently executed table command.

Syntax

_TALLY = nRecords

Arguments

nRecords Contains a numeric value indicating the number of records processed by the most recently executed table command.

Remarks

Certain table processing commands return information about their status (“talk”) while they execute. When such a command finishes executing, it displays the number of records it processed (if SET TALK is ON), and stores this number to the _TALLY system variable.

The following commands return status information:

APPEND FROM	AVERAGE
CALCULATE	COPY To
COUNT	DELETE
INDEX	PACK
REINDEX	REPLACE
SELECT - SQL	SORT
SUM	TOTAL
UPDATE	

When you start Visual FoxPro, _TALLY is set to 0. Executing one of the commands above replaces the _TALLY value with the number of records the command processed.
[end quote]

Well, it was true back in FPD2.6. Now indexing affects _tally only if you SET TALK ON, which is ridiculous - this is one situation where I absolutely don't need any progress indicator or any extraneous scribbling over my form. Gee, why did they have to fix it - it was never broken.

I've used "if recc()#0" instead and it works, but sometimes it won't do the trick - what if I wanted to have a filtered index or anything else of the kind, where number of available records is less than recc(). I'd have to Count - its results go to _tally regardless of Set Talk, but still it's an excess step which just induces unnecessary overhead.

Set Soapbox Off