True of course, but what I posted is of course extra junk included to demonstrate how the dlls work. However, in my testing, if the DLL is declared in advance (always exists for the timer's use) and the timer knows what file to always check for, you simply call funcFindFirst and test for hHandle (minus all the other stuff in this example to show how it works) and only call fileclose when necessary and not clear the dlls either because they should be available as long as the timer is running, it should be pretty fast.


>With all due respect, Tracy. I'd be surprised, very surprised if that function were faster than file() with all those statements and two declares
>
>
>>I'm not sure, but this may be safer (and faster) than IF FILE():
>>

>>CLEAR
>>
>>LOCAL lcFileToFind, llokay
>>lcFileToFind = "\mydirectory\mfile.txt"
>>llokay = findmyfile(lcFileToFind)
>>? llokay
>>RETURN
>>
>>FUNCTION findmyfile(tcFilename)
>>
>>DECLARE LONG FindFirstFile IN Kernel32 AS funcFindFirst ;
>>	STRING cFileName, STRING @WIN32_DATA
>>DECLARE FindClose IN Kernel32 AS funcFindClose LONG hHandle
>>
>>LOCAL lcFileName, lcBuffer, lcFilePath, llReturn
>>lcFilePath = ADDBS(JUSTPATH(tcFilename))
>>lcFileName = JUSTFNAME(tcFilename)
>>lcBuffer = REPLICATE(CHR(0), 318)
>>hHandle = funcFindFirst(tcFilename, @lcBuffer)
>>IF (hHandle > 0)
>>	lcFileName = SUBSTR(lcBuffer, 45)
>>	lcFileName = LEFT(lcFileName, AT(CHR(0), lcFileName)-1)
>>	? lcFileName
>>	funcFindClose(hHandle)
>>	llReturn = .T.
>>ELSE
>>	? lcFilePath+lcFileName+" Does NOT Exist"
>>	llReturn = .F.
>>ENDIF
>>CLEAR DLLS funcFindFirst, funcFindClose
>>RETURN llReturn
>>

>>Also, just as a test, if instead of an APPEND, if you step through the file and copy records one at a time (while slower), does the CPU Utilization still max out? I'm curious because I have seen CPU Utilization jump up to 90% doing an append in the past.