From Help: RETRY is useful in error-handling routines. It is frequently used to execute a command until a record- or file-locking function succeeds in locking the record or file. You can use SET REPROCESS to control retries of a record- or file-locking function. SET REPROCESS is preferable in most network situations.

I don't think I have ever used Retry myself. Nowadays I always use Try-Catch.Endtry blocks.

>Just curious,
>
>I was just experimenting and noticed this.
>
>If a subroutine is called as a procedure with a DO statement, the RETRY statement will execute the DO statement again as expected. But if the subroutine is called as a function, the RETRY statement acts like a RETURN command. I have not found any documentation that states is the case.
>
>Does anyone have any further insight to this?
>
>Here is a Test Case that demonstrates this
>

>*-- loopless Loop
>
>SET UDFPARMS TO REFERENCE
>
>LOCAL i as Integer 
>i = 0
>
>DO LoopLess WITH i
>? i      & 10
>
>i = 0
>= LoopLess( @i )
>? i     && 1, expected 10
>
>
>*-----------
>PROCEDURE LoopLess
>	LPARAMETER j
>	LOCAL llResult as Boolean
>	llResult = .T.
>	*
>	j = j + 1 
>	IF j < 10 THEN 
>		RETRY
>	ENDIF 
>	*
>	RETURN llResult
>ENDPROC
>
>* EOF
>