Focal Point
Report Developed in 4.3 Report Assistant, suddenly won't OPEN in 7.1.4

This topic can be found at:
https://forums.informationbuilders.com/eve/forums/a/tpc/f/7971057331/m/7771056602

January 11, 2007, 05:14 PM
debbiej
Report Developed in 4.3 Report Assistant, suddenly won't OPEN in 7.1.4
How frustrating.
An experienced user/developer calls to see if I've had any problems getting "older" reports to open in the recently upgraded 7.1.4. Report Assistant. He shows me his report and sure enough, when I try to OPEN it, I get the report code text box displayed with
line 1: Encountered "* .01 );

The report has a defined field that looks like this:
ExtStdCost/D12.2 = QTY * (STD_COST * .01);

WebFOCUS, all of a sudden, doesn't understand what * .01 is supposed to mean.

Disbelieving that this was possible, I recreated the report in Report Assistant. When I tried to SAVE the report, I get an ERROR PARSING PROCEDURE message that points to the defined calculation containing the * .01.

The solution? Add a zero before the decimal point. WebFOCUS 7.1.4 seems to understand the calculation
ExtStdCost/D12.2 = QTY * (STD_COST * 0.01);

Unbelievable. Like we don't have enough to do. Now we have to re-code all of our define calculations.

I found Mickys POLL below on WHAT SHOULD BE THE PRIORITY. I really think the IBI GUI developers should get serious about this. How can something as simple as not having a zero before a decimal point in a calculation break the GUI? And they can't understand why people don't want to use the GUI and are more comfortable coding?

Sorry for the venting, but sometimes it's just a little hard to take.

Deb


WebFOCUS 7.6.11 on Win2003 Server
WebFOCUS 7.7.03 on Win2003 Server
Published, AdHoc, ReportCaster
Output in all variants of Excel
January 12, 2007, 07:06 PM
Kerry
Hi Deb,

To get issues fixed, please contact Information Builders' Customer Support Service and submit a new case. This way we can send it to programming/product management to work on the issues. The phone number 1-800-736-6130, or please access online InfoResponse.

Cheers,

Kerry


Kerry Zhan
Focal Point Moderator
Information Builders, Inc.
January 14, 2007, 02:20 AM
susannah
hi debbiej,
speaking of whacky...
76 on the as400 does the following:
NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work
go figure.
i agree.




In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID
January 15, 2007, 01:55 PM
Francis Mariani
quote:
NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work


Susannah, and you still want to use Lazy If's? They're gonna disappear one day soon!

Cheers,


Francis


Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
January 15, 2007, 02:22 PM
Prarie
Interesting...I was taught to use it the way it is now working 7.6...but other developers said...no you can do it the first way Susannah listed...so I started doing that. Guess it will break when we upgrade to 7.6


In Focus since 1993. WebFOCUS 7.7.03 Win 2003
this particular edit can't break
if it does, then you can't edit an incoming &var , for ex, when you have no clue how long it is, and even knowing just isn't relevant.
this particular edit just strips off the first n characters of some string, regardless of the length of the string.
If they decide to break this, i quit.
and its only on Os400 for sure that this breaks.
and the bgh has agreed its a bug.
Can someone out there test it in 76 on a win plat?




In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID
quote:
NEWFIELD/A6=EDIT(OLDFIELD,'999999');
doesn't work
NEWFIELD/A6=EDIT(OLDFIELD,'999999$$$$');
does work

But, the question remains, does
 NEWFIELD/A6=EDIT(OLDFIELD,'999999$*'); 
still work?

Kevin


WF 7.6.10 / WIN-AIX
Unfortunately, * is not a valid mask character in EDIT.
quote:
EDIT works by comparing the characters in a mask to the characters in a source field. When it encounters a nine in the mask, EDIT copies the corresponding character from the source field to the new field. When it encounters a dollar sign in the mask, EDIT ignores the corresponding character in the source field. When it encounters any other character in the mask, EDIT copies that character to the corresponding position in the new field. EDIT does not require an outfield argument because the result is obviously alphanumeric and its size is determined from the mask value.

But, in v5.3.2, you can have more $ than the length of the input column. For example, this works:

TABLE FILE CAR
PRINT
COUNTRY
COMPUTE COUNTRY1/A1 = EDIT(COUNTRY,'9');
COMPUTE COUNTRY2/A2 = EDIT(COUNTRY,'99$');
COMPUTE COUNTRY2/A10 = EDIT(COUNTRY,'999999999$$$$$$$$$$$$$$$$$$$$');
END


Susannah, perhaps you could use a whole lotta $ in the EDIT statement when you don't know the length of the input column - just a thought.


Francis


Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
dude..not gonna happen Wink




In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID
The following would work for Dialogue Manager variables when the length is unknown:

-SET &OLDFIELD='This is the old field';
-SET &NEWFIELD=SUBSTR(&OLDFIELD.LENGTH,&OLDFIELD,1,10,10,'A&OLDFIELD.LENGTH');
-TYPE &OLDFIELD
-TYPE &NEWFIELD


Thanks!

Mickey

FOCUS/WebFOCUS 1990 - 2011
This define will fail with an error:
NEWFIELD/A6=EDIT(OLDFIELD,'999999$*');
because the RESULT of the EDIT is 7 characters, but the target is A6.
Why A7 -- since * is neither a 9 or a $, it is considered a literal that is copied to the output.
Susan, I tested the following on windows and it works fine.
DEFINE FILE CAR
X1/A6=EDIT(COUNTRY,'999999');
X2/A6=EDIT(COUNTRY,'999999$$$$');
X3/A7=EDIT(COUNTRY,'999999$*');
END


Brian Suter
VP WebFOCUS Product Development
Shouldn't the code become MORE intuitive and LESS redundant in higher releases?

Isn't it so much easier, nicer and understandable to code Susannah's EDIT function than this SUBSTR function?

I now have to go get my FUNCTIONS manual to see what the heck all those SUBSTR parameters even are ! ! Thanks Mickey Razzer . At least I will have re-learned something today ! !

And Francis, what would we do in the future release that makes entering more $$$$$$$ than the actual field length in the EDIT function an error? We're no better off, we just postponed the agony.

I still believe that IBI should STABILIZE a release (e.g, make everything work correctly) and PUBLISH the requirements (e.g., fully document the command structure) so we will ALL know what the rules are going forward. Then, any "modification" of those requirements in future releases would have to be fully documented and, hopefully, forward-compatible (e.g., if it worked before, it should continue to work, regardless of the modification).

I'm just not sure how we can continue developing our most-excellent applications not knowing what will cease to function (or require major rework) with the next upgrade because either we or they didn't follow someone's interpretation of the "rules".

Like Francis warns, the lazy ifs may disappear next. If they do, I will be re-writing A LOT of fexes . . . If it's not the lazy ifs, it could be anything else . . .

Kudos to all. Thanks for another entertaining and thought-provoking thread.

Deb


WebFOCUS 7.6.11 on Win2003 Server
WebFOCUS 7.7.03 on Win2003 Server
Published, AdHoc, ReportCaster
Output in all variants of Excel
quote:
But, the question remains, does
NEWFIELD/A6=EDIT(OLDFIELD,'999999$*');
still work?


The '$*' isn't a valid masking combination in the EDIT/Mask function but it is a valid wildcard representation in a selection statement.


ttfn, kp


Access to most releases from R52x, on multiple platforms.