A word about your DateRange Custom Function:
I have built a Relationship with DateRange CF to avoid comparable operators ( < > ≥ ≤ ).
I guess it was HOnzaKoudelka who claimed that comparable operators AND Cartasians ( operator 'X') are performance killers.
TableA::Start ≤ TableB::Date
TableA::End ≥ TableB::Date
TableA::f_DateRange = TableB::Date
In some rare cases, specially with PC, the TO would break since with FM Field of type 'Date', there is no control about wether the value is stored as
or anything else.
I guess we would need this feature:
2 of 2 people found this helpful
Cartesian relationship itself is not a peerformance killer, it evaluates instantly because there's nothing to compare.
For the purpose of consistent date usage - every date is actually stored as number internally. It just also stores the format in which the date was entered by the user. It's up to you as a developer how you decide to display it or convert to a string.
For relationship purposes, I suggest you always deal with integer numbers. Those are safest and fastest.
Just do GetAsNumber(date).
Performance will depend on calculations and evaluations and the depth of the links.
I agree, but I think we're moving away from the original topic
I never use DateRange (), I just put this code in the file, only to show that cfCall() can play recursive or simple custom functions.
Thanks you to test the file
Small reminder for those who want to relax with a bit of calculation and Filemaker !
The files are always open and nobody managed to break the thing
Have a good day !