progress 4gl - Conditions in FOR EACH which is TRUE regardless of database records? -

for each loan /* condition1 */ loan.date = somedate                 , /* condition2 */ loan.type = sometype                 , /* condition3 */ (if specmode true else loan.spec = somespec) 

condition3 = true when specmode = true. wonder if code above , code below work exact same (incl. speed) when specmode = true?

for each loan condition1                  , condition2                 , true 

or this?

for each loan condition1                  , condition2 

generally speaking question how progress manages conditions can evaluated regardless of database records. take more time? links how progress works in more deep view appreciated.

---

add 08/16/13: code i'm working was:

if specmode   each loan condition1 , condition2:     run proc. else   each loan condition1 , condition2 , condition3:     run proc. 

dynamic queries first idea came mind, realized mean rewriting of nested code dynamic queries style (which imo has worse readabilty, moved separate question). want go modern approach if it's reasonable solution.

there third way keeps code in "static style". using include files parameters. means .i file in huge codebase. , hate approach (as "cheating" preprocessor constants containing code). our system big , old , full of kind of things, harder analyze , seems not right.

the ( if ... ... else ... ) embedded in clause treated function.

in general preferable avoid having function calls in clause. some, not all, can resolved on server side. (user-defined functions , can-do() 2 examples must evaluated on client.)

in case don't know if true. if specmode true if false else portion evaluated , can't know how works out without looking @ data. not correct replace suggest.

if specmode always true then, yes, replacing suggest (both versions) work.

from efficiency point of view use of if function eliminates ability bracket on loan.spec field. if loan.date , loan.type leading components of index used bracket. if loan.spec index component cannot, however, used improve selection , whole subset of records carved out other criteria need examined individually.

i think code showing being used provide "clever" option of showing either records date , type, or subset of date, type , spec. might have been attractive (but hard read , inefficient) approach in old days. have allowed single block of code handle whatever inside loop body.

in today's world don't need that. write dynamic query , populate proper clause string use query-prepare on. way if loan.spec part of index can used support query , cases run much faster.