Long variable name losing value

[Bruce Easton]

Barry Wiseman wrote Friday, February 15, 2008 8:29 PM:
> 
> Bruce Easton wrote:
> > Barry Wiseman wrote Friday, February 15, 2008 6:47 PM:
> > 
> >> Bruce Easton wrote:
> >>> I'm seeing something kooky today where it appears that a long
> >>> variable is losing its value.
> >>>
> >>> Here is not all, but what I hope are the relevant parts of the
> >>> prc table (runs from clerk - 5.014):
> >>>
> >>>   1  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>          If:
> >>>        Then: exit
> >>>   2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> @menu    If:
> >>>        Then:
> >>>   3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>          If:
> >>>        Then: declare GLOBAL log_name(14,*)
> >>>   4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>          If:
> >>>        Then: '
> >>>   5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>          If: '[this is the ONLY called table (no chained tables)]
> >>>        Then: CALL "setup"      '[setup does not reference "log_name"]
> >>>   6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> .
> >>> .            '[debugger here shows log_name has a value]
> >>> 158  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> process  If:
> >>>        Then: 'process file
> >>> 159  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> .     [there are a couple of sys commands in here that are running
> >>> .      to completion OK]
> >>> 233  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>          If:  '[debugger shows log_name is blank and so is new(323)]
> >>>        Then: new(323)=log_name
> >>> 234  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> .     [there is an import here that is successfully assigning
> >>> .      to other 'new' fields]
> >>> 375  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>> enndd    If:  '[the record is being created, all but field new(323)]
> >>>        Then: close new                         '[populated OK]
> >>> 376  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> >>>
> >>>
> >>> To get around this, I have assigned a field ln(14,*)=log_name up
> >>> on line 4, then below that I now only assign 'new(323)' from ln.
> >>> Field new(323) is now getting its value OK this way.
> >>> Does anyone know why the long variable could lose its
> >>> value?
> >> Probably due to something that happens on lines 7-232. :-)
> >>
> > :):) That's exactly what I might have written had someone 
> > posted an example like this.  I was very careful to check 
> > all labels and refs to the variable, but I'll try to provide 
> > more code and info in another post.  I am showing all refs 
> > to "log_name."  
> > 
> > Bruce
> 
> I'm sure there are no intervening references to the variable, but 
> nevertheless some intervening *event* is at issue.  Does the value go 
> away following a CALL?  Following a SYSTEM command?  Following a popup?

It may go away following a system command - I'm just not sure yet 
how soon after.  I just got access again and what I did discover 
which really surprised me is that following Scott's suggestion 
also makes it work - that is making the long-var cross-rec global 
as in ,g.  As I said, this whole process runs just from @menu (and 
since it is a web event - it really has no choice but to run the 
table once from top to bottom - at least that is the intention).
When I substitute the long_var with the dummy ln (not global) in 
all the places log_name exists in the table, it also works.
Just to make sure - I put it back to not using log_name instead 
of ln and without the ,g - and it's broken again losing that value 
somewhere in the middle.  

Since this is part of a web process, I first was careful to make sure 
I was getting name value pairs everywhere I was expecting them.  
No problem there - that's when I went to the debugger and found that 
it is losing it mid-stream in a fairly simple top-down process.
Also since it is a web process there are no popups or processes that 
require user input prior to a page being rendered.

But I know the importance of your concern.  Quite often I see 
where someone fails to look at all the entry and exit points 
of the process while trying to debug or understand the program, 
whether they be goto's within the code, external calls or 
entry points from the outside (and of course - in what state does 
it terminate in the eyes of the database manager, were records 
locked, etc.).

Bruce

Bruce Easton
STN, Inc.