>>Lupdate() died on 1/1/2000 in FPW2.6; but appears to work fine in VFP6, 7
>>Is there still a real problem?
>
>I haven't used it since I got the Scripting.FileSystemObject; the object gets me information that LUPDATE() didn't (it returns a DateTime not only for last modified but also for last access) and works with non-DBF files (LUPDATE() sucks a value from the header of the DBF() rather than relying on file system date/time stamping.) For all I know, it works fine now; but it doesn't have a value to me, since I can get more accurate information for the cost of calling a COM object, or by using ADIR().

I agree; in fact I've never used LUPDATE(), but someone else might want to. It's there in the manual.

Here's the help snippet. Note the mistake on the century!!

"Note that in earlier versions of Visual FoxPro, the last two digits of the year a table was last updated is stored the table header. Because only the last two digits are stored, you cannot determine the century in which the table was updated, it always defaults to the 19th century."

19th century!! LOL, I didn't know that Fox ran on a Babbage difference engine.