Long variable name losing value
Barry Wiseman
bwiseman at optonline.net
Fri Feb 15 15:47:22 PST 2008
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. :-)
More information about the Filepro-list
mailing list