Hi - I’ve got a problem with a View Selection. I’ve got two text fields, SFMonth & SFYear. These have values like 01, 02, 03 & 2004, 2005 respectively. My select is not returning any documents - any ideas?
SELECT((Form = “Monthly Sales Focus”) & (@TextToTime(SFMonth) = @Month(@Today)) & (@TextToTime(SFYear) = @Year(@Today)))
Subject: Notes Views
You may be leading to bigger problems with view performance using a selection formula like this and the view increases in size. Why? because this formula has to be evaluated for each entry to decide whether or not it should be included or not.
There are alternative ways to get to the same place that may be more efficient.
SELECT((Form = “Monthly Sales Focus”) & IncludeInView=“Yes”.
(@TextToTime(SFMonth) & @TextToTime(SFYear)) that way you do not have to recalculate it every time (i.e. why recalculate a static value each and every time someone opens a view?).
Subject: Notes Views
Susan,
Instead of writing an agent to modify all the documents every night - that’s going to beat the hell out of the view indexer - you should instead write an agent to modify the view selection formula every night. A selection formula that compares the document to @Today, @Tomorrow, @Yesterday or @Now is bad, but a formula that compares the document to [04//12/2005] is OK. Since R5 the notesview object has had a selectionformula property. As of R6 that property is read-write, so just write an agent to change it once a day just after midnight and you’re done.
If you have users on the other side of the dateline you should consider putting in more than one copy of the view and altering the date value accordingly, and then figure out which view to show the user based on, I guess, their location document or maybe the timezone component of the current datetime. I haven’t thought that one through, but you get the idea.
Subject: Notes Views
I think it should rather be:
SELECT((Form = “Monthly Sales Focus”) & (@ToNumber(SFMonth) = @Month(@Today)) & (@ToNumber(SFYear) = @Year(@Today)))
Subject: RE: Notes Views
To Mika & File SAve 22 - thanks for responding so quickly - I’m going with Mika’s solution (I’m in a replicated environment) Thanks again - Susan
Subject: There is more to it than just what FileSave said about evaluating every entry.
Any view with @Today in it is always out of date and must be rebuilt on each access. If this view is filtering more than a couple of thousand documents, the performance will get very bad indeed. Much better would be a Nightly Agent to Turn on and off Flags that would allow it to appear in the view.
Subject: RE: There is more to it than just what FileSave said about evaluating every entry.
Well, there is still the Notes View option under View Properties/Advanced/Refresh, where you can say things like “Auto, at most every 24 hours” for example. But yes, these are just toys, and will probably not work properly in all situations, like when does Notes decide when the 24 hour period is over?An server based agent to set a field on the document based on the Today value is of course the best solution.
Subject: RE: Notes Views
Susan,
You should not necessarly go with what you see as the easiest path for you as a developer, but rather spend the time that makes the end-user/customer experience satisfactory. It is all about them.
Subject: RE: Notes Views
If I didn’t agree, I would think that sounded like sarcasm 
Susan, a lot of companies do not even allow the use of @Today in view selection or column formulas so you should try to avoid it. (There’s my two cents.)
Subject: RE: Notes Views
So - is it better to use @Now? or is that the same as @Today? (The view is a master list & will only have around 120 documents at most)
Subject: RE: Notes Views
Noooooooo! @Now is even worse, as it includes the time component, including seconds and milliseconds.
The only right way is to make a seperate field, which indicates if the document is to be displayed in the view or not.
I’m sure once you start implementing that, you will get quick examples how to make an server agent which computes that field, or you might not even need an triggered/scheduled server based agent, if you can make the field’s value calculation on the Form directly. As you have only 120 documents, you might as well resave them manually if you decide to go for the field calculation on the Form, which is of course nice, since then all documents are always up-to-date at all time.
If I don’t miss too much details here, your current view Formula of:
SELECT((Form = “Monthly Sales Focus”) & (@ToNumber(SFMonth) = @Month(@Today)) & (@ToNumber(SFYear) = @Year(@Today)))
could be easily rewritten as:
SELECT((Form = “Monthly Sales Focus”) & (MasterList=“1”))
and then you would create a new field on the Form:
Field name: MasterList, type: text, computed, value: @Text((@ToNumber(SFMonth) = @Month(@Today)) & (@ToNumber(SFYear) = @Year(@Today)))
Subject: RE: Notes Views
OK! I’m convinced! I’m going to add a computed field to the form & use that. Thanks everyone for your input. Susan
Subject: *I am never sarcastic;-)
Subject: Let’s make that “never MERELY sarcastic”, shall we?