>Because there is no ifs,thens, reccount() eof()s bof()s and other
>little traps comming to you now, or tmrw if you need to expand this *grouping* couple of more levels.
>Let say this was not simple Pk, but some composit 3-part key value and you hv to expand your (now) little procedure to act on 3 levels.
>Wld you still try to resolve it with countless ifs/endifs ?
>
>I use this code-idiom for very long time like off-the-shelf solution, in various *grouped* processing scenarious and never gave me single problem. Folowing the same logic you can add as meny inner scans (levels) as you want, having very flexible playground to group-procces records , calculate values, produce output and all other things you can possibly think of.
>
>Situation like your current problem, can be normally resolved in very little or no time at all, if you are aware of this conceptually, and you are simply implementing it - rather then reinventing it from scratch with ifs/endifs
>and getting entire UT Allianz involved over this.
>
>That is why I told you to keep in mind for some future implementations.
>Don't try to compare it with your code, just try to grasp the concept.
>
>If you were aware of it already, then I apologise for wasting your time.

I understood the concept which you explained. I don't remember if I used that concept myself before. AFAIK I always used single SCAN and did post-processing (repetative code) after the scan as well.

I'm just wondering, should I go ahead and change the program where I applied my own "innovative" solution or should I leave it as is and wait for the next opportunity to use the concept?
<g>

I actually did change the code and it is now much simpler.

Thanks again.