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?

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.

Hi Matt,

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

 

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" ).

 

 

@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.

7 minutes ago, Josh Ormond said:

order of tests. Can sometimes make a difference...

Yes, that's what I found, too:

1/0 or True

will not validate, but:

True or 1/0 

will.

Yeah. Crazy, right?!

Too bad the FM Community site is down for maintenance. I was going to see if this is an already reported bug.

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.

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?

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.

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 April 26, 20169 yr by comment

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.

That's not a problem ... it would be good then to begin your post indicating your OS and FM version to help us help you.  :-)