C
ChUIMonster
Guest
Your opinion is wrong 
Because this is an internal procedure you very much want to use a buffer scoped to the IP. If you just allow "free references" willy nilly you will be elevating the scope of the default buffer to the procedure block and causing unintended side-effects. Even if all you do is NO-LOCK reads this is a bad thing. My preferred approach is to include buffer definitions such as: define buffer customer for customer. for all of the tables referenced in an internal procedure. This ensures that no accidental side effects occur due to unintended references to the default buffer. Of course you should also define a distinct "update" buffer and use strong scope for any updates -- that's a second buffer.
Continue reading...
Because this is an internal procedure you very much want to use a buffer scoped to the IP. If you just allow "free references" willy nilly you will be elevating the scope of the default buffer to the procedure block and causing unintended side-effects. Even if all you do is NO-LOCK reads this is a bad thing. My preferred approach is to include buffer definitions such as: define buffer customer for customer. for all of the tables referenced in an internal procedure. This ensures that no accidental side effects occur due to unintended references to the default buffer. Of course you should also define a distinct "update" buffer and use strong scope for any updates -- that's a second buffer.Continue reading...