1 of 1 people found this helpful
I would do this personally, but it really isn't different than what you are doing:
Let ( [
TDY = Get ( CurrentDate ) ;
DT2 = Date ( Month ( TDY ) + 13 ; Day ( TDY ) ; Year ( TDY ) ) ] ;
DueDate <= DT2 )
PS: I would do it this way because "Get" functions are about the slowest functions in FileMaker, so this way only gets the Current Date once.
Thanks, I keep thinking that I might be missing a better way.
You could also settle for a less precise but similarly effective filter calc such as
DueDate <= ( Get ( CurrentDate ) + 395 )
As, I said, it's less precise for the exact date, but choosing a specific number of days into the future requires only one date factor in the calc, which might make filtering less costly to performance. Portal filtering performance has been taking a beating in numerous discussion threads.
You raise a good point. I wonder if anyone can definitively tell us which would work better/faster on FMSA12. I've heard that FMSA12 has moved filtering to the server level, so it seems that either would be fine, but I suspect there is a better approach. From personal experience, I can tell you that 12 is better than 11, as far as portal filtering goes, enough so that I can now leverage it for some clients and they're much happier.
You raise a good point. I wonder if anyone can definitively tell us which would work better/faster on FMSA12.
I am afraid you may be confusing two unrelated issues. Portal filtering is inherently slow - compared to adding a predicate to the relationship itself - because it works at the layout level and has to evaluate the filtering condition for each related record, every time the portal is redrawn. That's why the technique is unsuitable for large related sets.
However, the speed difference between calculating the exact date compared to approximating it is IMHO negligible.
I'm glad to hear that your experience with portal filtering in 12 shows improvement from 11. There have been other discussions claiming exactly the opposite experience. I suspect the details of the filtering make all the difference, but many writers complain without enough details to tell how they are filtering, whether using unstored calcs, or what.
It is my opinion that, as filtering is done live on whatever related records exist at the time using a calculation statement, portal filtering is a bit like applying an unstored calc field to a display in list view -- it's going to slow down refreshes. Still, how much it affects it will depend on how much calc resolving is required.
FYI, I'm not filtering against unstored calcs. In the past I was burned and found it very acceptable to add another field, set the filter to it, and things are well.
Have a great week.