in which case there may have been a duplicate name warning - best never to ignore warnings. I read recently (I think on the skype groups) that someone had “thousands of warnings”!
I use these prefixes to indicate the scope of variables
Glo: for global (defined in either dct or global section of the appgen)
Mod: for variables defined in the module
Loc: for variables defined in the procedure
Rou: for variables defined in the routine
Proc: for variables defined in local procedures within a proc.
Bad habit I know because ideally I would/should have used
Glo: for global (defined in either dct or global section of the appgen)
Mod: for variables defined in the module
Pro: for variables defined in the procedure
Rou: for variables defined in the routine
Loc: for variables defined in local procedures within a procedure.
ie swapping around the prefix for variables defined in the procedure and local procedures, but hey ho picking up bad habits off the ngs all those years ago and too much code to swap around at this stage.
Yeah, I should have looked. Code always trumps documentation.
2 Likes
Hard to mess this up using tablenames. Although I am gifted in this manner. 
Copying the code from routine to procedure and back to routine probably eliminates most of the usual screwups so IDK.
When I get a chance, I’ll compare the old/new routines and if those are the same, look directly at the code generated for the table handling and ignore the escaped curly-bracket comparison this time.
Hi I had another post here that got split into a different thread about the evils of using implicits. Just be aware that another possible reason moving from a routine to a procedure changed behaviour was if you have any implicit variables as their scope is different.
No implicit vars. I can’t remember the last time I used any, decades maybe. 
1 Like