DiffDays(PersonForm.Record.Person.DateOfBirth,CurrDate() ) < 0

Hi all,

In the development course we have to add a check if a record is filled in correctly.
The record is  " date of birth" and to be sure that the date is earlier than the current date I made the following condition:


SyntaxEditor Code Snippet

DiffDays(PersonForm.Record.Person.DateOfBirth,CurrDate() ) < 0 



This should calculate the amount of days between the filled in record and the current.
If it is filled in right this should be false.

During testing I filled in the date of birth: 2015-07-20

This should be greater than zero and still it is valid.
Can anybody see what I might be doing wrong

It will be used here: 

. Thanks in advance.
Regards,
Sander


Hi Sander,

Your DiffDays expression is correct.  There is no need to use this function, however, you could just compare the date with the CurrDate() function, so condition could be :


PersonForm.Record.Person.DateOfBirth > CurrDate()  



I'm assuming you're doing an exercise on form validation, and you want to give feedback to the user about the birth date not being before current date so they can correct it.  I'm assuming you are setting the Valid and ValidMessage runtime properties of the DateOfBirth Input widget in that Assign statement in your picture ?


So in case of your test with a date of 2015-07-20, the result of Diffdays(2015-07-20, 2019-07-20) is about 1500, this is not < 0, so I would expect the False branche of your If to be followed, and the CreateOrUpdatePerson to be executed, right ?  So it makes sense that in that case, the Valid is still true and the ValidMessage is empty, since you didn't pass through the Assign, right ?  So there are no problems with that test.


It's is a test with a future date that will be problematic, because there is still one piece from your logic missing : setting the Valid property on an Input widget in a form, doesn't in itself notify the user or stop the update from happening.  It does however cascade to the Valid property of the form : as soon as one of the widgets on it becomes Valid=False, then the form's Valid property is automatically switched to False as well.


So what is missing, is that right before going ahead and doing the update in the database, you should check if the form's Valid property is still True, in that case you can go forward with the update, otherwise, you should maybe give a feedback message and let the user correct the info, but not go through the CreateOrUpdatePerson node, because you don't want bad data stored in the database.


Hope this makes sense to you,

Dorine



Hi Dorine,

Thanks for your answer.
The code/ condition you suggested is more simple so for my convenience I implemented it.

The problem now it that any date of birth is written down in the database. So a date of birth before the current date and even an date of birth in the future.
Something is wrong with the check.  The assumption above about the excercise is correct by the way.

So used condition: 

SyntaxEditor Code Snippet

PersonForm.Record.Person.DateOfBirth > CurrDate() 


The assign:


It seems that something it wrong with the feedback message based on the filled in day of birth. Even with a date in the future no error appears.
I also tried to it to change the True/False-seting of the assign but still no message appears.

Regards,
Sander

After you set the valid property what ever, you need check the "Form.Valid". If it is false then show the feedback message.

Solution

Hi Sander,

you only flow to the assign when dates are larger then the current date, which is an invalid value, right ? So at that point (in the assign) you should set Valid to False, in your image it shows you set it to True.

And then if you put an IF before the actual update with condition <FormName>.Valid, and only go to the update on the True branch of that If, and maybe go to feedback and end node on False branch, you will be close to what you want, I think.

Solution

Hi Dorine,

I basicly forgot to implement the IF statement before the actual update.
Thanks for your reply.

Regards, Sander