<< Stored procedures are called like functions, can accept a standard argument list, pass results back to the calling program, and if programmed properly, can effectively use local variables. (Larry may nitpick this last point; what I like to do is use variables in stored procedures that begin with the letter 'p', then at the end, CLEAR VAR p%. The variables aren't truly local, but the SP has no variable footprint after the CALL, so I can pretend they're local.) >>
Well, as you surmised, I will mention that those local variables aren't really and truly local. I use the same technique that you do with "p" variables, except that I add some letters to try to make the variable prefix unique among stored procedures. So if I had a stored procedure LogUserAction, the variables would be named pLUA_. This is to allow one stored procedure to call another without the second procedure trampling on (or clearing) variables used by the first procedure. Of course this isn't foolproof because you could possibly use the same prefix in two stored procedures, but so far it's been good enough for me. The only thing I haven't been able to do is to eliminate a final calculated value in some stored procedures — ones where I can't "reuse" one of the automatically managed variables in the procedures parameter list. So, in the example given, I'll sometimes have a pLUA_Result variable hanging around after the stored procedure finishes. -- Larry
