So I guess you still use a steam engine in your car? And a black and white TV with vacuum tubes?

>Because it is a new thing you have to learn. Why should I be forced to learn something new when an ON ERROR can be made to work just as well as it did back in the dBASE days?
>(or at least that's how I interpret reaction I've seen from some folks)
>
>>Why would someone dislike TRY/CATCH when it's really a great and simple thing?
>>
>>
>>>>I have a SCAN-ENDSCAN loop with Millions of records in between. The records are infact the name of Files like C:\Bills\1.txt,c:\bills\2.txt.
>>>>
>>>>The code between takes the files and edit the TXT files as per my requirement.
>>>>
>>>>Generally Things go fine, however sometimes there are files with error inside TXT files only and my code does not satisfy the condition and therefore gives an error window like
>>>>
>>>>CANCEL,SUSPEND,IGNORE.
>>>>
>>>>At this time I Select IGNORE and my process goes further to the next record.
>>>>
>>>>Is there anyway by which is during course of SCAN ENDSCAN Error occurs, it should automatically IGNORE and move to the next record. so that I have not to wait infront of the screen for contionious monitorng
>>>>
>>>>If yes, kindly provide the piece of that Code.
>>>>
>>>>Regards
>>>
>>>
>>>As an alternative for all who dislike TRY..CATCH:
>>>
>>>

ON ERROR RETURN
>>>SCAN
>>>    .... Do your code here
>>>ENDSCAN
>>>ON ERROR

>>>
>>>You can also setup a handler to note certain things:
>>>
>>>

ON ERROR DO myErrorCatcher WITH lcTheCurrentFilename
>>>SCAN
>>>    lcTheCurrentFilename = however you get the current file name
>>>    .... Do your code here
>>>ENDSCAN
>>>ON ERROR
>>>
>>>
>>>FUNCTION myErrorCatcher
>>>LPARAMETERS tcBadFile
>>>    ? "A bad file was encountered: " + tcBadFile
>>>    INSERT INTO myBadFileLog ( cFilename) VALUES (tcBadFile)
>>>    RETURN

>>>
>>>Hope this helps!