>>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.

Any time :)