Buddy: Correct.
There's a nuance I didn't know until I read the article.
This variable is optimized:
SET VAR vhumpty TEXT = NULL
... this is not:
SET VAR vhumpty TEXT = 'wall_egg'
Best practice:
SET VAR vhumpty TEXT = NULL (outside the loop only)
...then:
SET VAR vhumpty = 'wall_egg' (inside or outside the loop)
I may have gotten sloppy in that regard.
Best, Bruce
------ Original Message ------
From "'Buddy Walker' via RBASE-L" <[email protected]>
To [email protected]
Cc [email protected]
Date 7/30/2026 12:01:00 PM
Subject Re: [RBASE-L] - IFF statement fail | Solution
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
On Jul 30, 2026, at 2:37 PM, '[email protected]' via RBASE-L
<[email protected]> wrote:
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 ------
From "'Karen Tellef' via RBASE-L" <[email protected]>
To "'[email protected]' via RBASE-L" <[email protected]>
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
On Thursday, July 30, 2026 at 12:37:14 PM CDT,
'[email protected]' via RBASE-L <[email protected]>
wrote:
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
[email protected]
(909) 238-9012
------ Original Message ------
From "[email protected]" <[email protected]>
To [email protected]
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
[email protected]
(909) 238-9012
------ Original Message ------
From "'[email protected]' via RBASE-L"
<[email protected]>
To "[email protected]" <[email protected]>
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
[email protected]
(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
<https://groups.google.com/d/msgid/rbase-l/em0a19783d-ef4d-4a17-9087-5bf33046be8d%40safesectors.com?utm_medium=email&utm_source=footer>.
--
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
<https://groups.google.com/d/msgid/rbase-l/emd690ac17-9c9d-4cb0-ac61-79e42c792c0a%40safesectors.com?utm_medium=email&utm_source=footer>.
--
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
<https://groups.google.com/d/msgid/rbase-l/680038837.2047838.1785434917266%40mail.yahoo.com?utm_medium=email&utm_source=footer>.
--
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
<https://groups.google.com/d/msgid/rbase-l/em28423046-2f73-44d2-9925-d078e9d80f03%40safesectors.com?utm_medium=email&utm_source=footer>.
--
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
<https://groups.google.com/d/msgid/rbase-l/941B131D-3402-4922-9832-9EBFA8A56D34%40comcast.net?utm_medium=email&utm_source=footer>.
--
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/em52672f0b-05a7-414b-85b2-19f05a54af07%40safesectors.com.
