>>>>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.
>
>David,
>
>Beginning with VFP 6.0 LUPDATE() returns the correct information.

Long time no comms; how are you there George? Now I have a team of clever people I'm not as active here anymore. Almost a "legacy programmer" :-)

Anyway, I'd identified that VFP 6 works in an earlier message. My point was that if VFP provides a function which gives you what you want then some folks will (rightly) use it. Don't really need a sledgehammer to crack a nut as so often happens in programming these days. Personally, I use ADIR(), and have rarely, if ever, required more information than that.
Best regards to you.