Larry,
I do something similar in my stored procedures (especially
TRIGGERS). TBI###, TAI###, TBD###, TAD###, TBU###, TAU### where
the A is an AFTER trigger and the B is a BEFORE trigger the IDU
values inticate INSERT,DELETE,UPDATE trigger point the ### is a
unique number currently tied to the SYS_PROC_ID in
SYS_PROCEDURES. If I need to retrieve data WHERE CURRENT OF
SYS_NEW/SYS_OLD I append a "N" for SYS_NEW and a "P" for
SYS_OLD. SYS_OLD a one time was a "O" but depending on font
wiat is letter o or number 0 hence the "P". A simple CLEAR VAR
TBI###% clears all variables created in that procedure. It also
has the advantage of allowing communication between procedures.
For example I change the Current Member Home Address I insert a
histry record of that address into a history table and update
counts in the Members Master record all done in a trigger
associated with the Current Home table. I also allow inserting
of a home history record directly into the history table. To
prevent the trigger associated with the histroy table from
double counting records I can set a TBI###HomeHist variable in
the Current home trigger which clues the Home History trigger
not to update the Member Master count.
Jim Bentley
--- Lawrence Lustig <[EMAIL PROTECTED]> wrote:
> <<
> 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
>
>
>
Jim Bentley
American Celiac Society
[EMAIL PROTECTED]
tel: 1-504-737-3293
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
