FLOAT ARRAYS in 4 GL reports 
Author Message
 FLOAT ARRAYS in 4 GL reports

Hi,

Former Informix 4Gl/ESQL programmerneeds help.

 I created a GLOBAL array of type FLOAT in the MAIN section of my 4GL
file. The data placed in it seems okay as I use DISPLAY statements to
view it. That works fine within MAIN.

When I attempt to PRINT the values in the array inside the body ofthe
REPORT,I get what appears to be random data.

Here's something else I tried. Instead of printing values extracted
from an array within the REPORT section, I tried creating a big string
by appending one value to the string and then continuing the process
within the FOREACH loop. That didn't work either. I was then going to
pass in the string as a value to the REPORT.

Somethinglike:

DEFINE big_str CHAR(180)

FOREACH .....
LET i =0

LET big_str = big_str || " " || float_array[i]

LET i = i + 1

END FOREACH

If you have any ideas, I'd be happy to hear and apply them




Mon, 21 Jun 2004 03:43:56 GMT
 FLOAT ARRAYS in 4 GL reports

Have you redefined the variable array elsewhere?

Quote:

> Hi,

> Former Informix 4Gl/ESQL programmerneeds help.

>  I created a GLOBAL array of type FLOAT in the MAIN section of my 4GL
> file. The data placed in it seems okay as I use DISPLAY statements to
> view it. That works fine within MAIN.

> When I attempt to PRINT the values in the array inside the body ofthe
> REPORT,I get what appears to be random data.

> Here's something else I tried. Instead of printing values extracted
> from an array within the REPORT section, I tried creating a big string
> by appending one value to the string and then continuing the process
> within the FOREACH loop. That didn't work either. I was then going to
> pass in the string as a value to the REPORT.

> Somethinglike:

> DEFINE big_str CHAR(180)

> FOREACH .....
> LET i =0

> LET big_str = big_str || " " || float_array[i]

> LET i = i + 1

> END FOREACH

> If you have any ideas, I'd be happy to hear and apply them



--
Paul Watson             #          
Oninit Ltd              # Growing old is mandatory
Tel: +44 1436 672201    # Growing up is optional
Fax: +44 1436 678693    #
www.oninit.com          #


Mon, 21 Jun 2004 04:54:58 GMT
 FLOAT ARRAYS in 4 GL reports
Quote:

> I created a GLOBAL array of type FLOAT in the MAIN section of my 4GL
>file. The data placed in it seems okay as I use DISPLAY statements to
>view it. That works fine within MAIN.

>When I attempt to PRINT the values in the array inside the body ofthe
>REPORT,I get what appears to be random data.

A really really REALLY big {*filter*} with 4GL reports is using global
variables on either side of the OUTPUT TO REPORT statement. What I mean is:

Consider a report to be two processes. There is a row-generating process
feeding rows into a row-consuming process. It's very similar to the way a
UNIX pipeline works, for example

uniq somefile | perl -e '.......'

However with a 4GL report, the "pipe" is the imaginary channel that OUTPUT
TO REPORT feeds. If you can read basic UNIX, I'm sure you'll understand that
it's a ridiculous idea to imagine the perl script is capable of or *should*
poke around inside the uniq process and mess with it's workings or rely on
the internal details of the workings of the uniq process.

Why is this so, as the hairy TV professor used to say?

Due to the nature of interpreting a report, the report may be a row or two
out of sync with the feeding process. The report might be stacking up a row
or two in preparation for some kind of page or group break. If you are NOT
using ORDER EXTERNAL in the report, then the report won't even kick in until
the entire row set has been fed to the report.

Since the report may be "on" a different row to the row-generating process,
if the row-generating process is also calculating some global variables and
expecting the report to use them, the report will be (from it's perspective)
looking at the "future" value of the global variables, and therefore the
values will be wrong.

The lesson to learn from this is that the report itself should ONLY use
either the report record passed in, or local variables it is calculating for
itself, or global variables it is calculating itself. If you have other
global variables which are generated from the outside, then you need to pass
them through the OUTPUT TO REPORT call. The only exception to this rule is,
the 4GL program may setup a global value such as a report title and the
report may use it as long as the value never changes. If it never changes
then of course you can't get into trouble.

Since you are talking about an array of FLOAT, you can't pass them to the
report so you'll have to pass enough information to the report so that IT
can calculate the information in the array. It may then be a local array
instead of a global, but it's no big deal either way. The row-generating
loop should only do enough work to be able to feed the source data to the
report for it's purposes.

The string you also mention is probably suitable for passing thru the OUTPUT
TO REPORT statement. The report loop will gather up each value and keep it
directly tied with all the other relevant data for that row.

I know this to be true because I've lost count of the number of {*filter*}, shaky
reports I've seen where the problems boiled down to this. Programmers will
try to get around the problem with more and more complicated flag variables
and all sorts of obtuse logic in the report, when all they need to do is
consider the separation of producer and consumer.
--
Space Corps Directive #997
Work done by an officer's doppleganger in a parallel
universe cannot be claimed as overtime.
    -- Red Dwarf
..  ... .--. .. -  --- -.  --- .-. .- -.-. .-.. .



Mon, 21 Jun 2004 06:51:39 GMT
 FLOAT ARRAYS in 4 GL reports
Quote:

>A really really REALLY big {*filter*} with 4GL reports is using global
>variables on either side of the OUTPUT TO REPORT statement. What I mean is:

Ahhh, that sentence should read:

variables on BOTH sides of the OUTPUT TO REPORT STATEMENT but hopefully the
following text makes that clear.



Mon, 21 Jun 2004 08:36:29 GMT
 FLOAT ARRAYS in 4 GL reports
Uh... I meant to say "I created a GLOBAL array of type FLOAT. (not in
the MAIN section, as I say below). Thank you.
Quote:
> Hi,

> Former Informix 4Gl/ESQL programmerneeds help.

>  I created a GLOBAL array of type FLOAT in the MAIN section of my 4GL
> file. The data placed in it seems okay as I use DISPLAY statements to
> view it. That works fine within MAIN.

> When I attempt to PRINT the values in the array inside the body ofthe
> REPORT,I get what appears to be random data.

> Here's something else I tried. Instead of printing values extracted
> from an array within the REPORT section, I tried creating a big string
> by appending one value to the string and then continuing the process
> within the FOREACH loop. That didn't work either. I was then going to
> pass in the string as a value to the REPORT.

> Somethinglike:

> DEFINE big_str CHAR(180)

> FOREACH .....
> LET i =0

> LET big_str = big_str || " " || float_array[i]

> LET i = i + 1

> END FOREACH

> If you have any ideas, I'd be happy to hear and apply them





Mon, 21 Jun 2004 08:58:32 GMT
 FLOAT ARRAYS in 4 GL reports
Quote:
-----Original Message-----
From: Finkel, Paul D, CFAUD

I eventually came to the same conclusion that you did ... but quite a bit
later. Your UNIX analogy is dead-on.

The GLOBAL array seemed like a good idea after having tried a few things
that didn't work. I guess I just haven't done much programming lately (last
3 years), but really can't use that as an excuse. I'll admit to NOT enjoying
programming in 4GL having done a fair amount of it when I started with the
company. But I do enjoy programming, even the failures.

Another question:The big string idea seems fine, but doesn't seem to work.
If I append  a float to a string, dose the compiler change the float to its
character representation?

Thank you very much for your superb and prompt help.
---End Original Message---

Shucks - glad to be of service.

The problem with all the 4GL manuals is, they don't warn you about this.
Although it's a VERY long time since I read about reports.... hmmmmmmmm

regarding the string:

I'm not exactly sure what your plan with the string was, but I can answer
some general stuff [hence putting this back to the newsgroup - other people
can probably benefit from it too]

To be really pedantic about the way the 4GL works, when you append a numeric
to a string, it takes a copy of the value of the numeric, converts that to
string (using the USING format that you might have coded) and then appends
that string to the other string. The variable holding that value is not
affected at all - it just sits there waiting to be referenced again.

If your "big string" is something like a char(1000) then you can be caught
out by the blank padding behaviour of 4GL chars. chars are actually
preferable (IMHO) to varchars because they are not limited to length of 255,
and they behave better when the string gets down to length one or zero.

Typical string activity usually benefits from the CLIPPED operator:

    let bigstr = bigstr clipped, " ", myfloat using "<<<<<<<&.&&"

If you don't clip bigstr at the front of the string, then it's full
allocation (eg 1000 including the blanks) has a space added (now we've hit
1001) then the converted float is added (let's say the length reaches 1010)
and then we stuff that result back into bigstr. But he's char(1000) so guess
what? Nothing apparently changes. With the clipping you get a much better
result. It's important to make sure that your chars get a haircut and get a
real job.

If you have to do something special when bigstr is empty (which is common
when building up a string in a loop) then you probably need something like
this:

    if length(bigstr) = 0 then
        let bigstr = myfloat using "<<<<<<<&.&&"
    else
        let bigstr = bigstr clipped, " ", myfloat using "<<<<<<<&.&&"
    end if

fussy programmers might use a temp string to hold the formatted value of the
number, then use that variable inside the IF-THEN-ELSE. The benefit of doing
that is, it's easier to make sure the USING formats are the same!-)

The use of length() instead of

    = " "
or
    is null
or
    = ""

means that you get sensible effects even if the string has been initialised
either to blank or null. It's a useful technique to know.

Does that explain what's happening with your string?



Tue, 22 Jun 2004 14:08:11 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. Storing arrays of floats

2. Array of float

3. float arrays

4. Storing Array of Floats in Access DB

5. How to use array insert to insert floats

6. Encoding and Decoding float arrays into images

7. Storing arrays of floats as images

8. Arrays of floats (query)

9. Informix Float on character arrays

10. Oracle Financials rel 10.7 GUI, GL, AP, FA, Reports, Contract


 
Powered by phpBB® Forum Software