<< Does the statement, RETURN .vETString, not only assign the value of vETString to STP_RETURN but, also, return control to the caller, therefore "bypassing" the CLEAR VAR statement? >>
Yes. << If this is true, what is the "best practice" for managing this situation? >> I can't claim to be an authority of _best_ practice, but here's what I do: 1. You can't clear the variable you use to hold the return variable, but you can clear all the _other_ variables immediately before the return. This leaves you with one variable taking up space. 2. I always name procedure variables with a special protocol. For instance, all variables in my procedure GetInteger are prefixed with pGI_. I know that any p variables that get left around can be safely cleared (CLEAR VAR p%) when I'm in code that can't possibly be run while in a stored procedure. 3. Whenever possible I return an expression or literal, not a variable: IF Something THEN RETURN (1) ELSE RETURN (0) ENDIF 4. Finally, here's a trick. If your stored procedure takes parameters, the named parameters will automatically be cleared by R:Base. If you can re-use one of the named parameters to hold your return value then it will be properly cleared for you. This only works if you have a parameter of the same type as the return. I would guess (but I haven't tried) that you could even create a fake parameter for this purpose, passing in NULL when you call the stored procedure. Unfortunately, this issue comes from the fact that R:Base has nothing like local scope. You need to make sure that your variables in the stored procedure don't conflict with any other variables in your application, or any variables you may decide to use in the future, or any variables that any other programmer who uses your stored procedure may decide to use in the future. That's why I think that the single best change that could be made to the R:Base programming language would be the addition of variable scope, preferably through the introduction of associative arrays (like in most modern scripting languages). -- Larry
