I feel like I'm missing something basic here. In PowerScript, Max()

returns the greater of two numbers. In a DataWindow, Max() returns the

largest value in a single column over all rows. I need the PowerScript

functionality in a DataWindow expression.

I have a computed field with a rather long expression in it. I need the

result of that expression to never be below one. If I put it in an if()

statement, then I'm calculating the formula two times (and have to type

it two times).

write a global function f_max(a,b) and call that in your datawindow

Put the formula in an additional computed field and refer to it. Invisible

in the finished app, temporarily visible for debugging.

"Jason 'Bug' Fenter [TeamSybase]"

That raises the question how PB's datawindow engine chooses

the calculation order for computed fields. Are computed fields

evaluated in the order they appear in the datawindow syntax?

That would be undeterministic because this order can change

when the datawindow is changed in the painter. Is that described

somewhere? I believe to remember one VPT to avoid referencing

computed fields (even in cumulated fields).

Chris Werner

f+s software gmbh

"Jerry Siegel [TeamSybase]" <jNOsSPAMsiegel@yahoo!.com> schrieb im

Newsbeitrag news:4939cdea$1@forums-1-dub...

Point well taken. I hesitate to suggest setting a computed column - sounds

like a lot of overhead.

It seems to use a single or maybe a double pass to determine calculation order.

I have reports which have computes based on other computes.

I also use subtotals that reference those computes rather than rewrite the calculation over and over and over again

My standard report processig does an explicit groupcalc().

If I didn't do the groupcalc(), some of the very complex reports could have some 'unfinished' computes;

98% of my reports don't need the extra groupcalc

So doing what Jerry suggests should work without any problem; and if it doesn't, just add a groupcalc

Yes, adding groupCalc() is another VPT which I use very often.

According to the documentation it "Recalculates the breaks in the

grouping levels in a DataWindow" but you are right, it is applicable

in a lot of situations.

I refrained from proposing it here because the OP was concerned

to "calculating the formula two times".

Again, it would be interesting to have some insight how PB's datawindow

engine chooses the calculation order for computed fields (that should be

simple if there are no cyclic definitions) and if there is some multi pass

processing used if needed (cyclic definitions).

BTW thinking about that I get this gut feeling that enforcing a certain

computation order and repeatedly calling groupCalc() until a result

reaches a fixpoint we could account DataWindow computed fields

syntax as complete programming language.

Chris Werner

f+s software gmbh

"M. Searer" <nospam@nospam.com> schrieb im Newsbeitrag

news:493dacd6@forums-1-dub...

I inherited a report once that did some calculations entirely in

computes that called global functions or were based on other

computes.

Sometimes the value of one of the fields would be displayed

incorrectly. Then if you scrolled the report up and down to push the

field off screen and back again, it would be displayed correctly.

AFAIK each compute is reevaluated every time it is painted on screen

(at least if a global method is called..).

Setting the background colour of the detail band to rgb(rand(255),rand

(255),rand(255)) certainly gives strange results...

I too would like to have the calculation logic defined so that we would know what to expect.

It should also allow sybase to test against that logic between versions, ensuring consistent results.