>This is what I ended up doing. The table in question is a derivative table. Actually one of several. These tables provide analytics/metrics to a web app. They are regenerated at specific intervals many times per day. If certain parent tables haven't changed since last time the derivative tables were generated, then the derivative tables don't need to be regenerated. That saves lots of CPU cycles and disk i/o. However, the timestamp on at least one derivative table needs to be updated to the last time the generator ran, even if the table(s) weren't regenerated. This timestamp update is so the web app can tell the user when the analytics were last performed. By the way, this all runs in a VFP COM DLL that is invoked by an ASP page that is invoked automatically by a scheduler.

>  USE (cTrackDataPath+ "BlahTable") IN 0 EXCLUSIVE
>  SELECT BlahTable
>  IF RECCOUNT()>0     && Touch it
>    GOTO 1
>    DELETE
>    RECALL
>  ELSE
>    ZAP
>  ENDIF
>  USE

>This approach always seems to correctly update the timestamp to current date/time on the server without changing the data. Zap works on a zero-record file. There are synchro objects in the web app that keep other threads from trying to access BlahTable while it's being updated.

Assuming the 1st record is never a deleted record, this'd do fine. If there's a theoretical chance the 1st record may be deleted, I'd propose a slight change:

set deleted off
  USE (cTrackDataPath+ "BlahTable") IN 0 EXCLUSIVE
  SELECT BlahTable
  IF RECCOUNT()>0     && Touch it
    GOTO 1
    if deleted()
        recall
        delete
    else
        DELETE
        RECALL
    endif
  ELSE
    ZAP
  ENDIF
  USE

So it preserves the deleted status of this record.