| I always made sure that variables data type were set before the while loop and never cleared them inside the while loop. After useing the variable you should set it to null or 0 depending on data type
Buddy Sent from my iPhone I've run with the default WHILEOPT ON for my entire R:BASE journey, where WHILE loops just keep on giving. 'Tis a mystery why this is the first time I've had to disable WHILEOPT.
So it's more'n likely I blew something here. I'll go forensic on my variable handling ... that article gave a good clue.
Thanks, K B
------ Original Message ------
Date 7/30/2026 11:08:37 AM
Subject Re: Re[2]: [RBASE-L] - IFF statement fail | Solution
Interesting! Just as an FYI, I never ever run with WHILEOPT ON. Every app I have, SET WHILEOPT OFF is in the startup code. If I have a little routine I run to set up development environment stuff just for myself, WHILEOPT OFF is always in there (along with other things that trip me up, like SET ANSI OFF)
I never once thought of asking about that cuz the problem doesn't fit the usual whileopt problem
Karen
Buddy, Jim, Steve:
In a quick, next morning response, support recommended SET-ting WHILEOPT OFF as the solution. That works, completed the module.
They also recommend the From The Edge article: "Understanding WHILE Loop Optimization", which I am mining for clues re: how I torpedoed optimization.
Again, I so appreciate your assistance. In friendship, Bruce.
Bruce A. Chitiea | SafeSectors, Inc. 1142 S Diamond Bar Blvd #442 Diamond Bar CA 91765-2203
(909) 238-9012
------ Original Message ------
Date 7/27/2026 2:17:32 PM
Subject Re: [RBASE-L] - IFF statement fail | IFFing Status
Buddy, Jim, Steve:
RBG11 11.0.3.20611
Worked your suggestions, performed a number of additional tests around the fail.
The bottom line is:
-- All rounding values are applied appropriately against values within their target range when in TRACE mode -- In RUN mode, the all-else rounding value (50) is applied against all values in all target ranges. -- Steve: The choice of operators within the IFF _expression_ does not affect the result. -- Jim: $25 is the correct rounding value for $13,437.17. -- -- In my TRACE mode test, rounding value $25 is applied, with the desired result $13,425.00 -- -- In my RUN mode test, rounding value $50 is applied, with the wrong result $13,450.00
If you'd like to test on your system, I've got a test set to send.
I'll poke around a bit more to see if I've created an underlying problem, then package for RDCC.
Thanks, Gents.
Bruce A. Chitiea | SafeSectors, Inc.1142 S Diamond Bar Blvd #442 Diamond Bar CA 91765-2203
(909) 238-9012
------ Original Message ------
Date 7/26/2026 1:37:04 PM
Subject [RBASE-L] - IFF statement fail
All:
RBG11 Current
For charting wide ranges of values, I perform incremental rounding to simplify display and interpretation (e.g. who cares about $13,437.17 when $13,500 will do? ).
This is the first time I've attempted to dynamically round with a full-set of preset increments, using this IFF construct (expanded for clarity ):
{Assign value-range incremental rounding values. } SET VAR v102_roundingValue = + (IFF('.v102_roundingTarget = 0.00 ', 0.00, + (IFF('.v102_roundingTarget BETWEEN 0.01 AND 4.99 ', 0.25, + (IFF('.v102_roundingTarget BETWEEN 5.00 AND 1000.00 ', 5.00, + (IFF('.v102_roundingTarget BETWEEN 1001.00 AND 10000.00 ', 10.00, + (IFF('.v102_roundingTarget BETWEEN 10001.00 AND 100000.00 ', 25.00, 50.00 + )) )) )) )) ))
This works ... sort of. When the routine runs outside of TRACE mode, all increments except 50.00 are ignored. All v102_roundingTarget values are rounded by 50.00.
And the kicker is, when I step through the code with F10 in TRACE mode, the proper increments are applied.
Does anything look out of place here?
Thanks much! Bruce
Bruce A. Chitiea | SafeSectors, Inc.1142 S Diamond Bar Blvd #442 Diamond Bar CA 91765-2203
(909) 238-9012
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/em0a19783d-ef4d-4a17-9087-5bf33046be8d%40safesectors.com.
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/emd690ac17-9c9d-4cb0-ac61-79e42c792c0a%40safesectors.com.
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/680038837.2047838.1785434917266%40mail.yahoo.com.
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/em28423046-2f73-44d2-9925-d078e9d80f03%40safesectors.com.
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/941B131D-3402-4922-9832-9EBFA8A56D34%40comcast.net.
|
