setting params when you define a dummy variable?

[Kenneth Brody]

Quoting Nancy Palmquist (Tue, 12 Apr 2005 17:23:48 -0400):
[... uncast dummy fields ...]
> >>You are right about RAM.  On undefined variables, filePro uses a new
> >>memory location each time the variable is assigned a value, instead of
> >>reusing the same location.  Most critical on Long reports that might
> >>then crash after enough records to eat up all the available memory.  I
> >>learned this one from experience.
> >
> > Except that the previous memory is freed for reuse, so you will not
> > see a runaway memory hog.  In fact, on most platforms, the only time
> > new memory will be grabbed is if the new value is longer than the
> > current value.
>
> I have documented cases where it was not released and the processed
> crashed.  Has this behavior changed over the years?  I think it was in
> 4.1 or 4.5 on a Unix system.

This behavior has been this way since 1.0.  Do you still have something
that could demonstrate a memory issue with this?

[...]
> >>ab="5"
> >>ac="6.2"
> >>ac=ab/ac
> >
> >
> > Field ac, being the result of a division, will be numeric.  (Assuming,
> > of course, that we're talking about undefined fields.  If ac is
> > defined with a length/type, then obviously it keeps that definition.)
>
> Mathematically, what could be affected is precision.  If the type of the
> numbers is not defined correctly, the result may not be to the right
> number of decimals or might have too few places.  This can be important.
>   I have also seen rounding errors where using more or fewer places can
> affect rounding choices on the results.

True.  If you need to control the type and precision of the fields, then
obviously you should define the field type and length.

[...]
> >>if: ab eq "0"	test false when you can clearly see the value of ab is
> >>equal to "0" but a literal zero not a numeric zero.
> >
> > If ab is numeric, then the above will be true if ab contains zero or
> > is empty.  If ab is not numeric, then it will be true only if its
> > first character is '0'.
> >
>
> Again, ab is not defined so contents could be anything.  Who knows what
> will be there.  How can you depend on results if the data is not
> controlled?

Yes, if you want/need control, then control it by defining the field.  I
was just pointing out that "ac = ab/ac" (with an undefined ac) will cause
field ac to be numeric, as "ab/ac" gives a numeric result.

> >>It can make things like numbers test wrong where they would right
> >>justify but literals do not.
> >>
> >>"2" is not equal to "   2"
> >
> > Again, it depends on the types.  If one of those values is in a
> > numeric field, then they are equal.  If they're both literals, or
> > non-numeric fields, then you are correct that they are not equal.
>
> He was asking about undefined dummy variables so they are all literal.

Well, ac="2" could be true, as ac in the above example would be numeric.


Bottom line, undefined fields have their uses, but if you want/need the
control over the length and type of the field, then you should define
it with that length/type.

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com