setting params when you define a dummy variable?

[Kenneth Brody]

Quoting Nancy Palmquist (Tue, 12 Apr 2005 16:35:59 -0400):

> Mike Schwartz wrote:
>
> >      I have been doing some programming for a customer who usually
> > doesn’t put any length or edit type on their dummy variables. 
For
> > example:
> >
> > Ky=”Smith” or ky=”10” * xy
> >
> > Instead of:
> >
> > Ky(30,*)=”Smith” or ky(15,.0)=”10” * xy
[...]
> > I thought there were some downsides to not setting a length or edit
> > type, like extra RAM memory wasted.  This is probably a “Ken
Brody”
> > question and maybe even a good topic for the filePro room tonight, but
> > are there any other reasons why it might be good or bad not to put
> > edit types on dummy variables?
[...]
> 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.

However, variables with a defined length are allocated memory once, and
that memory is reused every time.  Variables with undefined length do
have extra overhead involved when assigning to them, as new memory may
need to be allocated every time you make an assignment to them.

> Also, you are right about math.  Undefined variables are assumed
> literal.  So doing the following:
>
> 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.)

> might result, in some cases, in issues caused by changes from literal
> --> to decimal  -- > to binary.  I remember running tests on this and it
> might be possible also to have things like:
>
> 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'.

> 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.

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