>When you RETURN from your error handler you will return to the line following the line of code of that generated the error. If you RETRY instead, execution will go back to the line of code that caused the error and retry it.
>
>Since your error handler is a procedure and not a function there is no where it could store a return value to.
>
>As for your example, I think it is better to simply check:
>
>

IF USED( 'mytable' )
>  SELECT myTable
>ELSE
>  USE mytable
>ENDIF

>
>HTH
>
>>I have a table updating program (program 2) which is used to print a tickler chart for our Social Workers. This program will be called from a menu (program 1). The program returns .T./.F. to signify success or failure of the update (to program 1). Within the program (an independant .prg file) I have an error handler (program 3) that gets call using ON ERROR DO ErrorHandler. Since this error handler is setup to handle Unanticipated errors such as, USE XXX when XXX is in use allready, I wanted it to return to the calling program (program 1) .F. for no success. I mistakenly used the syntax RETURN .F. TO &lcProgramName where program name equaled the name of program 1.
>>
>>Closer examination of the help file revield I could say RETURN .F. or RETURN TO &lcProgramName but not both. I can setup a global variable in Program 1, set it in the error handler and check it on return but that seems much messier than the way falsely attempted to do it.

I'm sorry, I chose a bad example. I used this one only to keep the question simple. My intent is to handle "unanticipated errors". I can and do use the USED() system to check for table usage my intent was to handle those errors I did not account for or were cause by an aberation.

A closer representation of the code I was trying to implement follows:

LOCAL llSuccess
llSuccess = .F.
llSuccess = UpdateMasterChart() && This is a prg
IF !llSuccess
[Deal with it]
ENDIF !llsuccess

*********************************************************
* UpdateMasterChart program .prg
* seperate file
*********************************************************
ON ERROR DO ErrorHandler
PUBLIC gcCallingProgramName && Program above's name
[code to set gcCallingProgram value to name of above program]

.
.
.
code
.
.
.
RETURN(.T.)



****************************
** PROGRAM ERROR HANDLER
** subroutine of MasterChartUpdate
*******************************
[Display error message with information to tell programmer for
unanticipated errors]
[Handle anticipated possible errors]
RETURN .F. TO &gcCallingProgramName

This returns control to the top program which is in position to deal
with the results through llSuccess



All this I decided last night (sleep is a wonderfull thing) was the wrong way to approch the problem. I have a form available to me to set the criteria for the update. I think I will place the program and the error handler in custom methods on the form and if an error occurs I will set a custom form property to .T. and return to the form. The form can check for the exitance of .T. in the property and handle the consiquences.

If anyone has a better thought I am ALL EARS

Thanks
Terry