Jump to content

Birthdate field allowing 4 digit years won't work


This topic is 2258 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Use-case:  Full birthdate is not known…  only the year.  Better to have a valid 4 digit year OR a full, valid date than whatever the user feels like entering.

The field is Contacts::Birthdate (Text).

Field validation by calc is turned on with this code:

Let(

[
    d = Self
];

IsEmpty(d) or
d = GetAsDate(d) or
(d = Filter(d; "0123456789") and Length(d) = 4)

)

If I enter nothing in Birthdate, it is accepted.

If I enter "4/25/2016" in Birthdate, it is accepted.

If i enter "2016" in Birthdate, it is rejected as not meeting field validation requirements.

BUT, if I run the code below in Data Viewer, it evaluates as true (or "1"):

Let(

[
	d = "2016"
];

IsEmpty(d) or
d = GetAsDate(d) or
(d = Filter(d; "0123456789") and Length(d) = 4)

)

The problem seems to revolve around the Filter() function, but enclosing d in GetAsText() or GetAsNumber() does not help.  Can anyone tell me why I am getting different logical results between my Data Viewer and the field validation?

Link to comment
Share on other sites

I suspect it has something to do with GetAsDate.

"2016" = GetAsDate( 2016 )  // false

GetAsNumber("2016") = GetAsDate( 2016 )  // true

By the way, seeing as GetAsDate( 2016 ) evaluates to 7/9/0006, you might want to validate against a date range rather than just accepting any old date.

Link to comment
Share on other sites

This is a strange bug.

How to prove it is a bug:

1. Validate a field by the following calculation:

Let ( [
error = 1/0 ; 
$$result = error or True
] ;
$$result
)

2. Open the data viewer and monitor the value of $$result.

3. Enter any value into the field.

You will see that validation fails, despite $$result being evaluated as 1. This seems to be a side-effect of the calculation encountering an error along the way - even though the error has no effect on the final result.

The error in the given example is caused by evaluating GetAsDate ( "2016" ).

 

 

  • Like 1
Link to comment
Share on other sites

@HazMatt

Move the "GetAsDate" test to the end.

Let(

[
    d = Self
];

IsEmpty ( d ) 
or d = Filter(d; "0123456789") and Length(d) = 4 
or ( d = GetAsDate(d) ) 


)

This is something I heard talked about at PauseOnError. Not this particular problem, but about order of tests. Can sometimes make a difference...

I would submit this one as a bug, though. It's not right!!

As a side note, this only works if the error ( as @comment showed in his calculation ) will only work in the validation if the error is generated last.

  • Like 1
Link to comment
Share on other sites

P.S. IMHO, the correct approach to the actual problem would be to have three number fields: Year, Month and Day. And probably a calculation field to calculate the date: a real date for those that have all three values, and a default date for those that don't.

Link to comment
Share on other sites

Fascinating…  glad I'm not crazy or [too] stupid!

I figured out a more "pure" way to accomplish my goal, one that would work no matter what the order of the tests was in:

Let(

[
	d = Self
];

IsEmpty(d) or
IsValid(GetAsDate(d)) or
(d = Filter(d; "0123456789") and Length(d) = 4)

)

 

1 hour ago, comment said:

P.S. IMHO, the correct approach to the actual problem would be to have three number fields: Year, Month and Day. And probably a calculation field to calculate the date: a real date for those that have all three values, and a default date for those that don't.

For the record, I agree… sort of.  A field named "Birthdate" should be a legitimate, valid date.  But there are trade-offs to the suggested approach…  4 fields instead of 1 make for a wider table and a more complicated user interface that precludes the use of the drop-down calendar and possibly acrobatics to simulate a single field when there are three.

 

3 hours ago, Lee Smith said:

Please update your Profile to reflect your current version FileMaker, platform and OS.

Do I have to?

Link to comment
Share on other sites

14 minutes ago, HazMatt said:

Do I have to?

Why the reluctance? The information helps us to determine what tools you have available so we won't include replies that include tools that you don't have.

Link to comment
Share on other sites

13 hours ago, HazMatt said:

there are trade-offs to the suggested approach…  

There are trade-offs to everything. I'd much prefer not to have a field that draws values from two different domains (dates and years) and eventually is neither. You cannot sort by such field and any calculation referencing such field is going to be much more complicated than it should be (witness your validation formula).

 

Edited by comment
Link to comment
Share on other sites

12 hours ago, Lee Smith said:

Why the reluctance? The information helps us to determine what tools you have available so we won't include replies that include tools that you don't have.

I really don't mind, but I just rarely visit the forums these days, so it would likely be out of date next time I post something.

Link to comment
Share on other sites

This topic is 2258 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.