I've created a validation calculation for looking up or entering a subset of newer customers and am wondering if I could have achieved this more elegantly? Or worse that there is an error I;m not picking up!

The Customer numbers follow a standard format of a letter C followed by 9 digits where the first three numbers are always 0 (C000######)

Case ( Length ( CUSTNUMBER ) ≠ "10" ; "0" ; Left ( CUSTNUMBER ; "4" ) ≠ "C000"; "0"; Exact ( Right ( CUSTNUMBER ; 6 ) ; Filter (Right ( CUSTNUMBER ; 6 ) ; "0123456789") ) ≠ "1"; "0"; "1")

I am trying to ensure that the user always has 10 chars, with the 4 left chars always being "C000" while the the right 6 chars are always integers.

Any ideas?

if(

left(CUSTNUMBER;4) = "C000" and

Length(CUSTNUMBER) = 10;

Length(Filter(CUSTNUMBER;"1234567890")) = 9 ;

"1";"0")

I did not tried but i think this calc. works

I was under the impression that "case" are marginally better than "if" for some reason I can't remember, or am I mistaken?

Anyways I could only get the if statement work as

If(

Left(CUSTNUMBER;4) = "C000" and

Length(CUSTNUMBER) = "10" and

Length(Filter(CUSTNUMBER; "1234567890")) = "9" ;

"1";"0")

With a single test, it doesn't matter if you use If() or Case(). But here you don't need either - you can write just this:

Left ( CUSTNUMBER ; 4) = "C000" and

Length ( CUSTNUMBER ) = 10 and

Length ( Filter ( CUSTNUMBER ; "1234567890" ) ) = 9

Note that Length returns a number, so there is no need to wrap the other number in quotes.

What really puzzles me is why do you allocate 12 digits to customer number in the first place, if you then forbid the use of the leftmost three?

I was under the impression that "case" are marginally better than "if" for some reason I can't remember, or am I mistaken?

Gnat farting perhaps, but where they differ is the flexibility in use ...it easier to change your mind when debugging a Case( while doing the same with IF's will easily make a nested mess to read - and especially here where neither is required at all.

But what have happened with Case( is in order to make thing evaluate a tad faster, have the previous OPN method been rejected, so the statement only procedes the evaluation until a match is reached, ignoring that following condtions might give a match as well.

--sd

The Case() function short circuits: once a true statement is found it stops evaluating and returns the result. The If() function evaluates everything, so nested Ifs can be measurably slower.

Not sure whether Else If changes this.

There is no Else If function.

The Case() function short circuits: once a true statement is found it stops evaluating and returns the result. The If() function evaluates everything, so nested Ifs can be measurably slower.

Unless it's just a matter of your wording, I'd have to disagree with you. If() short-circuits as well; along with NOT, AND and more. The only difference between Case() and If() is, as indicated, if one changes their mind it's easier to adjust and add more tests.

LaRetta

Take the nested IF conditional statement below:

If ( functionA ;

If ( functionB ;

If ( functionC ;

trueresultC ;

falseresultC ) ;

falseresultB ) ;

falseresultA )

I believe that even if functionA evaluates to false, functionB and functionC will still be evaluated.

Comment: yup, Else If is a script step.

I believe that even if functionA evaluates to false, functionB and functionC will still be evaluated.

I don't think so. Here's a simple test you can use to check this:

Set Variable [ $calc; Value:If ( 0 ; Let ( $$test = Get ( CurrentTimeStamp ) ; $$test ) ; "false" ) ] 

Show Custom Dialog [ Message: $calc &¶& $$test; Buttons: “OK” ] 

Ok, I stand corrected!

Wow, I didn't expect to see so much discussion on my little validation problem.

Thank you all for making my kludge a little less kludgey and clarifying the "If" and "Case" issue.

The reason why I have to use such painful customer numbers is due to the legacy Oracle system and someone else's choice for 9 digits, the "C" really gets my goat...

Once more, thanks all!