views:

80

answers:

1

Hi, I have a datawindow containing multiple fields. I want to write a validation expression for a field named amount. I have another two fields named debit and credit. If the sum of debit and credit is greater than amount, then I want to show a validation message to the user.

How can I write the required validation expression in the Column Specification of that datawindow?

I also want to write validation expression for a field named test. There is a field named criteria. When this field is set to 1, I want the test field to be a required field. How can I write validation expression for this?

+2  A: 

There are different ways to do this, depending on whether you have to use the column's required validation expression or have the license to do it different ways.

Design Considerations

Is this going to be a freestyle datawindow where you only need to validate the rule once for the screen, or a tabular style where users can mass enter sets of data and the rule needs to be applied to each row?

Do you want to require the users to enter the correct values each time a required field gets focus or do you want to let them freely navigate the screen and validate at save time?

You'll get some different responses here, I expect, but I prefer to use the column specification expressions only for simple checks because:

  • Complicated logic in there tends to get hard to read and maintain
  • If you have multiple error conditions you're checking for, that can lead to some unwieldy messages if you use the column specification's built-in error message field

However, I'll grant that dw expressions are generally really fast.

Using a Computed Field for Validation Rules

One alternative technique is also a fast performer and can be used in most versions of PB.

  • Have a computed field on the datawindow that has a meaningful name such as cf_amount_rule and something like this in the expression: if (debit + credit = amount, 0, 1)
  • Make that field invisible to the user if you want
  • Add another computed field in the footer to sum cf_amount_rule and you now have a handy reference point that quickly tells you when there is an error
  • At save time (or the pfc_validation event for PFC users) you can check for sum > 0 and post an error message

OO purists might suggest that it's wrong to put logic in the datawindow and if you find yourself putting in the same rule in multiple datawindows that's certainly a code smell. But for simple rules that are unlikely to change I have found time and again that the datawindow is very efficient at running these rules and saving you from having to write lots of code elsewhere.

Optional Goodies

  • You can make the error message more robust by using the find() functionality to identify specific rows with the error
  • You provide useful visual cues to your users by changing the row or a field's background color via property expressions that reference cf_amount_rule.
Bernard Dy
I didn't understand one thing : why do I need to sum cf_amount_rule?
Night Shade
@Archangel: You don't have to add the sum field. You can do nearly everything you want with find(), but if you wanted to get a count of how many rows (if you have several rows of data in the datawindow) were failing validation, the sum tells you. Without it you'd have to iterate through the dw to count the occurrences, or use some other PB trick like filtering on cf_amount_rule = 1, both of which would require more work than just referencing the sum.
Bernard Dy
@Bernard: Or li_ErrorCount = Long (dw.Describe("Evaluate('sum(if (debit + credit = amount, 0, 1))',1)")) to do it completely in PowerScript
Terry
@Archangel: This is appropriate if the rule is that the transactions have to balance on a row-by-row basis. However, the former accountant in me thinks this is on a total basis. The same technique (as above) can be used to calculate the sums in PowerScript, e.g.: ldc_DebitSum = Dec (dw.Describe("Evaluate('sum(debit)',1)")). And yes, you could put the sums as computes in the DataWindow and do a GetItem*() on them. Depends on whether you want to keep your logic together.
Terry
I still find your "computed field for validation rule" useful. Thanks!
Night Shade