Long variable name losing value
Brian K. White
brian at aljex.com
Fri Feb 15 18:53:29 PST 2008
----- Original Message -----
From: "Bruce Easton" <bruce at stn.com>
To: "filepro list" <filepro-list at lists.celestial.com>
Sent: Friday, February 15, 2008 9:05 PM
Subject: RE: Long variable name losing value
> 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.
ln or log_name defined or referenced anywhere in auto or selection processing?
Since this is @menu and thus clerk, it can't be the thing I hit in @once vs @wb* in report a few months ago, but maybe it'll help to remind us of other hidden gotchas.
Basically I did not know that in report, main record processing and each break processing each maintain their own distinct copy of each dummy, and I managed to discover a way to trip over that even though I was not doing anything that involved record to record summing (which feature I _was_ aware of).
I was filling a ,g global dummy with a string that included rand() (a temp file name), once only, in @once. Then only reading the dummy elsewhere. Yet, I would not get the same value in @wb that I created in @once. Turned out fp was executing the rand() function multiple seperate times to fill each internal copy, and so they all got different values. None of their values changed over time or from record to record or across events. Merely @once's copy was different from @wbfoo's copy right from the outset. Hilarity ensues.... :)
Talk about "not what I was expecting" as Tyler puts it in the other thread. :)
--
Brian K. White brian at aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
More information about the Filepro-list
mailing list