January 11, 2007, 05:14 PM
debbiejReport 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
January 12, 2007, 07:06 PM
KerryHi 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
January 14, 2007, 02:20 AM
susannahhi 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.
January 15, 2007, 01:55 PM
Francis Marianiquote:
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
PrarieInteresting...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 |
January 15, 2007, 03:16 PM
susannahthis 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 |
January 15, 2007, 03:57 PM
KevinGquote:
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
January 15, 2007, 04:54 PM
Francis MarianiUnfortunately, * 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
January 15, 2007, 09:48 PM
susannahdude..not gonna happen
| In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID |
January 16, 2007, 09:00 AM
mgrackinThe 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 |
January 17, 2007, 01:35 PM
Brian SuterThis 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
January 17, 2007, 02:06 PM
debbiejShouldn'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
. 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
February 27, 2007, 01:47 AM
Piipsterquote:
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.