<< For instance, by default I start variables with the letter 'v', but in stored procedures will start them with 'p' or 'p' and 'r' (in an update trigger, for 'prior' and 'revised') so that I can "CLEAR VAR p%' and not impact my form or calling command file. >>
I go a step further and give every routine a two-to-four letter prefix in addition to the "v" for variable, "f" for form, "r" for report, "p" for procedure and "t" for trigger. For instance, my stored procedure DateWhere (which takes two dates and a column name and returns a WHERE clause fragment) uses variables that all being pDW_ . A routine from a codelocked APX file that was called PrintInv would have variables all named vPI_ something. And a form named EditInvoice1 would have variables fEI1_. That way, I can call different routines and at the end of each routine do CLEAR VAR pDW_%, CLEAR VAR vPI_% or CLEAR VAR fEI1_%. It's not fool-proof, of course, because calling PrintInv from inside PostInv would cause problems, but since I started doing this I think I've had one case of namespace collision. -- Larry
