Prarie,

The answer is to hang on in there. All the time there is a form of FOCUS/WebFOCUS the old coders will always be needed

Liken it to the time when everything was done in assembler, or if you are really sad - yes I own up to this one - coding in hex!! Assembler programmers are still in demand - albeit to a lesser extent nowadays.

Keep the chin up!

T

7.1.3 looks pretty good to us. We did uncover a few problems during testing, mostly as a result of tighter syntax enforcement or corrected errors:

Using SQL pass through, DB2 VARCHAR fields are written to HOLD as AnnV. This caused a –READ error for us. We fixed the problem by adding ENGINE DB2 SET VARCHAR OFF to the server profile. It looks like the default changed in 7.1.3 (or the setting was not available in 5.3.2 – I forget which).

CTRAN no longer works if you specify a data length that actually exceeds the length of the data.

In 5.3.2 the extra (non-display) field(s) created by explicit reformatting are incorrectly counted when figuring column position using C notation in stylesheet (COLUMN=Cn). 7.1.3 correctly excludes them from the calculation. Of course, our programs had to be adjusted, as they were compensating for the problem.

In 7.1.3 we found that a multi-page compound report sometimes came back completely empty. Running the same exact same report over and over, we sometimes got a correct, fully populated report, and sometimes we got a report with nothing but blank pages. The problem only occurred using Adobe 6.0. Switching to Adobe 7.0 solved it
We found one other, very odd, way to solve this problem. The report in question contains a drill down. We found that if we shortened the length of the drill statement by removing a variable (any variable), the problem disappeared.

We have a UI that allows the user to select multiple instances of a variable (call it &X). In 5.3.2, when the user selected only one value, WebFOCUS would create &X. When three variables were selected, it created &X, &X0 (number of variables), &X1, &X2, &X3. One of the values the user might select is ‘ALL’. Naturally, when specifying ‘ALL’, only one variable is selected. When processing this variable, our code first checked for &X = ‘ALL’. If true, WHERE processing was bypassed. And &X was always present, no matter how many values were supplied by the user. In 7.1.3, however, this technique does not work, because &X is not present when multiple values are selected.

My favorite issue.

Save a fex that contains a line with only a dash in it and see what happens. (Make sure you save everything else before you do this.)

Try this code out:

-* File test.fex
-

I beleive this only happend in 7.1.3, I think 7.1.0 and 7.1.1 worked fine.

Another "gotcha" - reading variables from save file e.g.

....
ON TABLE SAVE AS TEMPVARS FORMAT ALPHA
END
-RUN

-READ TEMPVARS &MyVar.A20.
....

Whereas in 5.3.2, if your variable length was actually 12 then the read would only read a complete line. Now in 7.1.3 (Windows), it will read beyond and onto the next line. Therefore your first &MyVar would contain the 12 chars from the first row of SAVEd output, plus the first 8 chars from the next line.

i.e. If your saved output was :-

ENGLAND_____
FRANCE______

Your first &MyVar will contain "ENGLAND_____FRANCE__"

Other consequences will be that if you perform a repeat using &LINES then your fex will error due to reaching EOF prematurly.

This is not a bug but (IMHO) pure interpreter tightening, as you should always ensure that you know the length of record you are holding. However, it is worth bringing to the communities attention because we all know that sometimes we forget to check

T