I want to be able to show in a view documents and their responses only if the documents have a creation date of the previous year. I can’t seem to get a formula with @created and @today to compare with any results. Any recommendations?
Subject: RE: Comparing creation date with todays date
The phrase “the previous year” is vague. Do you want a view that displays only those documents where @Year(@Created) has the same value as @Year(@Today)-1? Or one showing documents where @Created < @Adjust(@Today; -1; 0; 0; 0; 0; 0)? Or something else?
In either case, do be aware that from a performance standpoint, the use of @Today in a view selection formula is discouraged. What task do you want the user to accomplish with this view? Do you really need a view that has only old documents, or can you manage with a view that shows all the documents, oldest documents first?
Subject: RE: Comparing creation date with todays date
Thanx for your response and sorry for the vagueness. Yes I want to a create view that displays only those documents created in 2006 and previous to 2006. When we enter in 2008, I want the view to display only those documents created in 2007 and previous to 2007 - without having to modify all the views with the current year.
I have tried @Year(@Created) < @Year(@Today)-1 but view has for some reason has no results.
Subject: RE: Comparing creation date with todays date
So I got the following to work:
& @Year(@Created) < @Year(@Today)
If you do not suggest using @Today for performance reasons, why would you suggest instead?
Subject: RE: Comparing creation date with todays date
Subject: Thanx. This seems to work…
This seems to work:
@Year(@Created) < @Year(@TextToTime(“Today”))
Any reason not to use it?
Subject: RE: Thanx. This seems to work…
As I say in the blog entry that Harkpabst linked to above, the problem with this is that the view contents don’t change when “Today” changes. The view will look OK until the end of this year, and then it will be still showing the documents from 2006. You have to do one other thing to make the server realize that it has to re-index the view. There’s a way to set up a scheduled server command, which you can use to rebuild a view index. It needs to be done on all servers, but in your case, it only needs to happen annually.
This works if your application is only on servers. If there are local replicas you have to do something more to support those. That’s why it’s so much easier to use an agent to update the view selection formula annually. It works in all replicas, it’s a few lines of code using the NotesView class, and Bob’s your uncle.
Subject: Once a year run an agent that sets a field that indicates the document is not this year.
Then have a view that only shows the documents where that field exists.
Subject: Gotta be something easier than that???
Not looking to create an agent - looking to keep it a view.
Subject: RE: Gotta be something easier than that???
developerWorks has a couple of articles dealing with this. Make absolutely sure you understand all the implications of using @Today or @Now in a selection formula, before making your final decision. Even more since you really need a change only once pr year.
Also check Andre’s blog to learn, what is NOT an alternative.
http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/today-in-a-view
Personally, I’m a big fan of modifying the selection formulas of views through a back-end agent. Don’t need to modify documents for that. You just need an agent that can run with designer access. Other options are available, just search developerWorks for @Today.
Subject: RE: Gotta be something easier than that???
Subject: RE: Gotta be something easier than that???
Yes, all true. And I have used @TextToTime(“Today”) in the past myself. Even more so since Notes 6, which brought an important improvement:
In prior releases, the literal “Today” was recognized only on English Notes/Domino installations, e.g. @TextToTime(“Today”) returned “” on a German client. So, for localized clients you had to provide the matching term in whatever language was installed. If you had to support multiple languages for international organizations that could result in a number of @If conditions.
Since Notes 6, localized clients can always be reverted to English (except for what comes from single-language databases, of course). This is handy anyway, especially if it comes to searching for error messages. As a side effect (or maybe the intended main effect, who knows), @TextToTime(“Today”) now works for all locales.
The reason why I linked to Andre’s blog was just to make clear, that @TextToTime(“Today”) is not a drop-in replacement for @Today. I’m probably a bit sensitive here, because that’s what I was told, when I was starting to learn Notes (and it took me a while to recognize, that this was not true).
After reading your posting, suggesting the use of @TextToTime, I considered this to be the best solution as well for this particular problem. However, after thinking about it for a while, I’m not 100% sure, if you really get away without setting up a program document. It’s true, that most probably the view will have been rebuild over the course of a year several times. But most definitely, users will want it to be up to date exactly on January 1st (or maybe 2nd). So, I think you have to somehow rebuild the view anyway at least on that day. And that makes other alternatives just about as good.
Or am I missing something?
Oh, and since we are on Notes 6 or 7, we could also use @ToTime. Wouldn’t make any difference in this case, but … well, its all NEW (only just 5 years old)!
Subject: RE: Gotta be something easier than that???
Subject: RE: Gotta be something easier than that???
“I was thinking maybe a Post-It on the admin’s calendar to open the view and press Ctrl-Shft :p”
LMAO! Help!
But probably still a good idea. 