I have created a view, with up to 6/7 categories. However, I don’t think this tend to take up that much time right?
I have other columns, which has values like Current Month, YearToDate, YearEndProjections, which are time dependant, ie the values is Actual+Forecast, which depend on what is the value of current month, i.e time-dependant, the only way to avoid time dependant is to have 12 views instead of one, but the column will not have to refer to today’s date. (but wonder won’t 12 views reduce the time to upload?)
I also has a text column, which take up text data from up to 20 fields, but this don’t take that much time right, so I just keep it?
Another option, I will come up with an agent to do view refresh background (sorry, just a theory for the time being, but have not got time to explore its possibilities?).
So, in a nutshell, wouldn’t just create an agent to update view background is the easiest option for me? Only problem is that this is still in theory, hopefully I will came across previous posting that might have this coding.
Subject: My plan to reduce view index rebuild time
I would recommend stamping documents via an Scheduled agent stamping documents with appropriate flag based on time parameters and then refreshing view simply by using the notesView.GetFirstDocument method. Otherwise your time criteria within view requires a rebuild of view every single time its opened.
Subject: My plan to reduce view index rebuild time
Embedding @Now in your view calculations will have a dreadful impact on performance and that, as well as other time-date calculations should be avoided at almost any cost.
My most recent approach to the problem of forecasts has been to embed a view with a category calculated on a specific time frame (in my case a month) into a form. Control the single category from a date field on the form. This is much more efficient than using multiple views and your users will thank you for offering them a simple interface.
To get around the problem of using data from multiple documents in a single view row, I have used the technique of creating disposable documents with the specifically required fields created on demand from the parent form. This allows you to present a dynamic forecast to your users with no date dependancy problems and minimal presentation delay. Run a scheduled agent to remove the documents after they are discarded; you can do this overnight because these documents will never be seen outside of the specific user request.
Subject: My plan to reduce view index rebuild time
Create one view with the month/year categorized. Then have a page that has the view embedded. Make it a single category view that uses computes the current month/year value.
Have your users open that page instead of the view, or write code in the view’s query open that closes the view and reopens the page instead.
Subject: RE: My plan to reduce view index rebuild time
Yes, @Now, compared against MonthField and YearField. so I thought of 12 views, referring to 12 months, so the column’s value will not be dynamic anymore.
Subject: My plan to reduce view index rebuild time
Consider hard-coding date values into the various columns, and then running a LS agent once a day to alter the various column formulas. Of course the resulting view would not make sense if someone was looking at the view from, say Korea.
You can do likewise with the selection formula of course.