×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Douglas Handy wrote:
Then a second pass standardizes the data in each column to the maximum size
and decimals detected for that particular column during the first pass.
There "coldta" is the contents of a column of data but the size can't be
determined at compile time as in:
D zeros s like(coldta) inz(*zeros)
I don't agree with you. The code I work will work perfectly well
despite the size being unknown at compile time. Think about it. The OP
defined a variable called ColDta that he stored the column data in. How
could he possibly do that if he doesn't know the size of the field? The
answer is simple: ColDta is defined as the MAXIMUM possible size of a
field. Since it's a VARYING field, he can set the length to be smaller.
My code, similarly, will work. It doesn't matter that you don't know
the field size at compile time, because I did the following:
coldta = %subst(zeros:1:cwdth(#col)-%len(coldta)) + coldta;
%subst() is a BIF that lets you take PART OF a string. When I do that,
I can control the length of the data I use in the expression.
So I was *not* assuming that he knew the size of the field at compile
time. Incredibly, I was able to glean that the size wasn't known from
the other 500 times it was stated in this thread.
It is also why the values aren't known at compile time for using some of the
other techniques proposed.
Yes, I get that. I would not have proposed those techniques. Unlike
certain others, I KNOW that *ZEROS can't be used as the first parm of
%SUBST(), and I KNOW that you can't use a variable for the length/decpos
of %DEC(). It's not rocket science after all. %DEC() controls the size
of an intermediate result. Think about it...
Surely you understand that an intermediate result is -- basically -- a
variable generated and used by the compiler. (Under the covers.) in
order to change it's length/decpos, the compiler would -- essentially --
have to *recompile* the program. Think about it.
What I don't get here is why it is desirable to standardize the columns into
what in essence is fixed width sizes with leading or trailing zeros, up to
the maximum length of any data in that "column".
Yes, that was MY question as well. I can fully understand the idea of
loading a variable amount of data -- and I *did* take it into account
when I wrote my code, as I've hopefully clarified above.
What I don't understand is why you'd want to fill the silly thing with
zeros. What good does that do anyone?
midrange.com
