Validating Field Input During UPDATE

[Rio38]

I am trying to validate the input of a field during the UPDATE block. I have a simple date range and I want to make sure that the second date entered is greater than the first date entered. I have the followign code in place for the UPDATE, but it is not passing validation no matter what dates I enter into the fields. The second date always fails validation.

UPDATE
                loc
                loc1
                dept
                dept1
                upartlist
                ly-n
                edate
                edate1 VALIDATE(edate1 > edate, "Invalid Date")
                excelfile
             WITH FRAME a.

 

[joey.jeremiah]

if a value has not been entered for anyone of the date variables their value would be null (?)

http://en.wikipedia.org/wiki/Null_%28SQL%29

in which case the validate expression won't succeed.

try the following validate expression -

edate1 validate(
 
       edate1 = ?       /* max value is blank, nothing to validate */
    or edate = ?        /* min value is blank, nothing to validate against */
    or edate1 >= edate, /* otherwise max date must be >= min date*/
 
        "Max date must be bigger or equal to min date. Please re-enter." )

you could write a support procedure that will handle common user interface behavior, like -

switching range field values, incase max < min,

copying range field min value when first entering max field, many times range is used as an equality filter etc.

 

[Rio38]

I added the code you provided because I did not think about the user leaving the fields blank, but that doesn't seem to help the problem. When I add the "or" conditions, the field does not validate at all, it accepts any value for edate1. If I simply have VALIDATE(edate1 >= edate) the validation fails no matter what I put into the edate1 field.

 

[joey.jeremiah]

i was sure i tested the first code snippet i posted before i left the office ( 9.1c unix ).

here's a more explicit version -

edate1 validate(
 
       input edate1 = ?
    or input edate = ?
    or input edate1 >= input edate,
 
        "Max date must be bigger or equal to min date. Please re-enter." )

 

[tamhas]

There are a couple of issues here. I know that what you want is a simple answer based on using a validate clause in an update statement. I will let others bash that out with you if they can.

But, I'd like to suggest that you start thinking about replacing UPDATE with WAIT-FOR, i.e., making the move beyond version 6 Progress. There are many things, including this kind of multi-field validation, which are controllable in more straightforward ways with triggers than with UPDATE.

Moreover, you should also think about whether you should really be doing this at all. I recognize that there is a business logic requirement that one date be equal to or greater than the other. But, the question is, when it the right time to enforce this. If you use validate, you trap the user in the update statement until they "get it right" or hit F4 to exit, discarding anything they have done. This can be unfriendly if, for example, a user is interrupted by a telephone call and needs to access some other part of the application and then is forced to either abandon work or come up with revised entries under pressure. Instead, you might want to consider validating the values *after* the update statement at the point where the work is going to be committed. I don't know the context in which this update statement is being used, but if there is any aspect in which the user might want to do something else, look up something else, etc., and then come back to these values and put in the desired dates, you should allow that.

 

[Rio38]

Thank you all. I did end up using validation after the UPDATE statement in the form of an IF..THEN statement. I am still not sure why the VALIDATE statement was not working to begin with, and that still worries me, but it works and is fairly clean.

 

[joey.jeremiah]

rio,

did you try the code snippet ? i tested all the combinations, hey, it works for me ? oe10, winxp.

i completely agree that validate in particular is mostly unpractical, because it doesn't allow the user to leave the field until it passes validation.

of course i agree on wait-for and event-driven user interfaces, modern design patterns, like, mvc and more over the big question should be about starting the move into a modern architecture.

i'm guessing this case has more to do with query filters then committing transactions and proper business logic validations, but none the less its a chance to ask a few questions

in an architecture, like, oera there would be a service that could satisfy the request in a single call to a method and any exceptions would be passed back to the client, right ?

 

[Rio38]

I did try the code snippet. It seems to bypass the validation statement all-together regardless of the criteria I try to validate on. I am not sure why this is happening. I am going to validate it after the update statement for now.

I agree that the wait-for would be better, I will have to explore that for the future, as I have never used that before.

Thanks again.

 

[tamhas]

rio,
of course i agree on wait-for and event-driven user interfaces, modern design patterns, like, mvc and more over the big question should be about starting the move into a modern architecture.
...
in an architecture, like, oera there would be a service that could satisfy the request in a single call to a method and any exceptions would be passed back to the client, right ?

Well, that might be a bit simple. If this information is being stored in the database, then certainly this validation will occur in the data access layer before it is stored and failing the validation there would push an exception back to the business logic and that in turn might push it out to the UI or wherever it happened. Depending on the client type, one might or might not include such validation in the client, but it would be advisory, not binding, until one tried to commit. Like those web pages where you click on Continue or Save and it pops back up with something in red ... that could come from a smart enough client or from the model portion of the UI back on the host. It is appealing to think of putting this logic in one place, but primarily it needs to be in the domain object. Then, the data access layer can ask the domain object to validate itself prior to saving and the business logic layer can ask the domain object to validate itself at any appropriate transition, such as receiving new values from the UI.

 

[it@flude.co.uk]

The validate command seems to fire at the end of the update.

Try putting a trigger like this in your code:

on leave of edate1 in frame a do:
if date(edate1:screen-value) <= date(edate:screen-value) then do:
message "Invalid Date" view-as alert-box.
return no-apply.
end.
end.

 

[joey.jeremiah]

it@flude.co.uk,

the problem with validate is it doesn't allow the user to leave the field until he gets it right.

you could move the validation to the end when the data is submitted (could also be used with update).

on "go" of frame a anywhere do:

    if  input edate2 <> ? and input edate <> ?
    and input edate2 < input edate

        then do:

        message
            "Max date must be bigger or equal to min date"
        view-as alert-box error.

        apply "entry" to edate.
        return no-apply.

    end. /* edate2 < edate */

end. /* go of frame a */

this code could be written dynamically as part of a common user interface behavior.

you could also use the input-value attribute.

For any widget that has a SCREEN-VALUE, INPUT-VALUE returns the unformatted value of the widget’s SCREEN-VALUE, in the native data type of the widget.

 

[joey.jeremiah]

Thomas,

I still have lots of catching up to do on architectures and I'd like to ask a couple more questions on OERA if I can -

1. Assuming it is desirable to conserve AppServer calls as much as possible, ideally satisfy a request with a single call. Should services be built so they can satisfy every request in a single call or as close as possible to that idea ?

2. Continuing the first question, are Business Entities the foundation services, sort of speak, that on top of them larger composite services can be built, like, Business Tasks and Business Work flows ?

Thanks in advance.

 

[tamhas]

I have moved the OERA discussion to here http://www.progresstalk.com/showthread.php?p=332456#post332456 since it isn't really related to this thread.