dummy fields & auto processing

[Richard Kreiss]

Top Post:

Would the fact that ct was set to a single value in auto processing affect
its size in input processing?

i.e. ct = "A" carry forward to input where ct="AB".  Would ct being seen as
a 2 character field in input or a one character field?

Richard

> -----Original Message-----
> From: Kenneth Brody [mailto:kenbrody at spamcop.net]
> Sent: Monday, February 03, 2014 1:08 PM
> To: Richard Kreiss
> Cc: filepro-list at lists.celestial.com
> Subject: Re: dummy fields & auto processing
> 
> On 2/3/2014 12:56 PM, Richard Kreiss wrote:
> > Windows
> > Filepro: 5.7.03
> >
> > I ran into a problem today with an uncast dummy field ct.
> >
> > In auto processing ct is set to zero ct="0"
> >
> > In input processing at one point ct is initialized to "1" as the first
> > index value for an array filled with values from another file.
> > Originally the array had only 8 elements.  The number of records that
> > needed to be read changed to 15.
> >
> > I changed the dim foobar(8) or dim foobar(15) and changed the loop to
> > read the records from:
> >
> > If: ct lt "8"
> > Then: ct=ct+"1";GOTO loop
> >
> > To:
> >
> > If: ct lt "15"
> > Then: ct=ct+"1";GOTO loop
> >
> > When I checked this line with the debugger and ct = "1", the statement
> > came back as false.
> >
> > When ct was replaced by c(2,.0), the program worked as expected.
> >
> > Why would ct  lt "15" return a false when ct was set to 1 and
> > displayed a 1 when checked with the debugger?
> 
> Because, without the (2,.0) definition, nothing in the code you list above
> would cause ct to be a numeric field.  Therefore you are comparing the
string
> value "1" to the string value "15".  And, just like the string value "B"
compares
> equal to the string value "Brody", those two values would also compare as
> equal.
> 
> When you were comparing single "digit" values, it didn't matter.
> 
> --
> Kenneth Brody