Column 1, sorted Categorized

DT := @Date(EventDate);

DT:

@Adjust(DT;0;0;1;0;0;0):

@Adjust(DT;0;0;2;0;0;0):

@Adjust(DT;0;0;3;0;0;0):

@Adjust(DT;0;0;4;0;0;0):

@Adjust(DT;0;0;5;0;0;0):

@Adjust(DT;0;0;6;0;0;0);

Column 2, Sorted

@Date(EventDate)

Then just @dblookup on todays date.

The big test for performance is the frequency of documents changing VS the data read frequency.

An expensive view action can make sense when the data is not changing often and retrieved value is used often.

First off, is this an intranet app? If so, a browser standard should allow you to do XML client side (in theory). If so, this could be relatively simple...

What I'm getting at is -?ReadViewEntries- and the optional URL arguments that were added for the iNotes team (without these, don't ask me how they'd have accomplished the Calendar portion of iNotes). OK, by now it's Domino Web Access instead of iNotes...I'll catch up. :-)

The ones in question are:

- KeyType

- StartKey

- UntilKey

With KeyType, you can tell Domino to treat the StartKey and UntilKey as dates (check "URL Commands" in Designer Help, or the link above for "website"). Here's a snippet:

-----

If &KeyType=time is specified, then &StartKey and &UntilKey may be ISO date time values. For example, you might use the time value 20020101T140000,00Z to represent 9:00AM Eastern standard Time in Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT), or you might use the time value 20020101T090000,00-05 to represent the same date and time in local time plus offset.

-----

Using those, and client side XML transforms, all you'd need is a view sorted by EventDate. Avoid the daily agent, avoid numerous folders, and avoid @Today selection formulas. Then again, I'm probably missing something. :-)

Of course key factor is whether or not requirements allow you to code for only AJAX capable browsers...

Create a Program document that runs Updall -- use this method to schedule Updall to run at particular times.

e.g.

load updall database.nsf -T "viewname"

Then schedule it for whenever you want

Hope this helps

Ed. I'm confused now. I'm going to have to play with this one and see if it can eliminate the need for nightly agents.

Could not just use @TextToTime("Today") in your view selection and then create program document to do an updall on that specific view?

It's a simple solution that is easy to maintain/

Ed

I have used @Today in views (albeit in the Notes client) without any unacceptable performance hit or delay to the user. Other options are listed in the document.

found this somewhere on the net but haven't used it yet. The example was

SELECT ((@TextToTime(Today) - CREATIONDATE)/86400)

cheers Tom

I know I'm coming late to the party... but if the right solution (and by right I mean, works best with least code) is a SQL Query, has there been any discussion with the client about backing their domino websites with something more robust for data? I know that means a lot more work than any solution identified, but where there is one clear need for this kind of data flexibility, there may be more. Perhaps their Admin or System Architect would be receptive to expanding the capabilities and you'd have yourself some work updating their templates. :-)

A tangent, but I try to consider all the possibilities when I start running into too many difficulites with a particular approach. While more involved, it seems cleaner.

Best of luck in any case!

Jerry

i seem to remember that any functionality you placed under the views "Form Formula" and the "Helprequest" would be cleared after altering the view via LScript version 6.x .

Build the view - categorised by date. Then on the form doing the lookup, set your 7 dates in a list and use @transform like so:

@transform(date_list; "X"; @Dblookup("";"";"eventsview"; X; 2))

The results are already sorted because you make sure the date list is sorted to begin with.

Is this crazy talk?

I could have gone with three "all" views plus three views per feed, but the massive number of view rebuilds that would occur every night when the selection formulae are updated would scare me even if the database were a lot smaller, so there was no way I was going to go this way.

In theory, I could use just six views -- three uncategorized, and three categorized by feed, and adjust the selection formulae nightly. Chaanging the selection formulae would result in complete rebuilds of all six views every night, but with only six views this may not be too bad. There are two reasons why I didn't do this, though.

The first reason I didn't do it is that -- hust as is the case with readernames fields -- single category view displays can get quite slow when there are thousands of documents that have to be skipped in order to locate the ones that are actually displayed, so I decided not to go that way. In my own use, the number of documents that would be selected in the seven day categorized view is only around 5000 at any given time, and that's below the threshold where performance issues tend to set in, so I could probably have used the views and show single category, but my goal was to build a behind-the-firewall re-aggregator that could scale to thousands of feeds, with potentially tens of thousands of current in a seven day span.

The second reason that I didn't do it is that you can't control the order of view rebuilds. There's no guarantee that the order in which you update the selection formulae is the order in which the rebuilds will occur. Although the worst thing I can think of happening in my application if views were updated in an unusual order is that there could be a significant time lag during which many documents appear in the 1 Day\All view but aren't in the 1 Day views for their particular feed (or vice versa), it still seemed to me that making a major design feature dependent on the order of view rebuilds was a bad idea.

So, I went with the folder approach. Or, I guess I should say the massively mulitplied folder approach ;-) I set up folders for All\1 Day, All\2 Days, and All\7 Days, and the code also sets up a 1 day, 2 day and 7 day folder for each individual feed that are added. As they are created, new documents get put in the 1, 2 and 7 day folders for their particular feed, and also in the 1, 2, and 7 day "all" folder. A nightly agent traverses the All\7 Days folder and removes documents as needed -- from that folder and also from the others as needed. The performance has been consistently good, the massive number of folders required has (so far) not been a problem, and while the agent takes quite a while to run the performance impact on the server while it is running is barely noticeable.

I'd prefer to consider using the @TextToTime("Today") solution. Does anybody know if this is correct. Not that I don't trust SearchDomino.com or anything, but I'd like to see some concrete proof this is any better than using @Today. Seems like the same thing to me, in terms of the view index.

1) Upon saving an Event, use a wqs agent to set the isNextWeeksEvent field to be 0 or 1.

2) Have the MeetingsNextWeek view's selection criteria of being isNextWeeksEvent = 1

3) Run a scheduled (daily) agent to reset the isNextWeeksEvent field value if it needs to be changed.

I agree about the overnight agent updating the selection formula - I really think the template problem is a nasty one.

Jake yesterday mentioned that he stopped when he considered something a hack. Well running an overnight agent to update a view is something that I would consider a hack.

Why should the design have to be modified everytime? Surely this is quite a major hack.

Just a @dblookup to grab the code, no administration problem.

But that's something you have to live with too I guess.

I'm not too sure about it either - I love the fact that you can update view formulas like this but these two factors (the template one especially) are a bit of a worry.

be adapted for dates, numbers, etc.

(I think I got this from LD6 forum, so thanks to whoever originally wrote it):

Public Function SortDocumentCollection( dcol As NotesDocumentCollection, fieldName As String) As Variant

'Sort documents in a collection in alphabetic order by the field specified

'STM 2001-10-05

Dim session As New NotesSession

Dim db As NotesDatabase

Set db = session.CurrentDatabase

Dim array As Variant

Dim k As Integer

k = dcol.count

If k <> 0 Then

Redim array( 1 To k )

array = docCollectionToArray( dcol )

' // Need to add a value at the end that will always be greater than all - language dependent

Redim Preserve array( 1 To k+1 )

Set array( k+1) = db.CreateDocument

Call array( k+1).ReplaceItemValue( fieldName, "ÅÅÅÅÅÅÅ" )

array = QuickSort( array, fieldName, Lbound(array), Ubound(array) - 1 )

Redim Preserve array( 1 To k )

SortDocumentCollection = array

Else

SortDocumentCollection = ""

End If

End Function

Private Function QuickSort (array As Variant, fieldName As String, leftpos As Integer, rightpos As Integer) As Variant

'Sub function in SortDocumentCollection

'STM 2001-10-05

Dim i As Integer

Dim j As Integer

Dim pivot As String

If ( leftpos < rightpos ) Then

i = leftpos

j = rightpos + 1

pivot = Ucase( array(leftpos).GetFirstItem(fieldName).Text )

Do

Do

i = i + 1

Loop While Ucase( array(i).GetFirstItem(fieldName).Text ) < pivot And i <= rightpos

Do

j = j - 1

Loop While Ucase( array(j).GetFirstItem(fieldName).Text ) > pivot And j >= leftpos

If ( i < j ) Then

array = SwapInArray( array, i, j )

End If

Loop While ( i < j )

array = SwapInArray( array, leftpos, j )

Call QuickSort( array, fieldName, leftpos, j - 1 )

Call QuickSort( array, fieldName, j + 1, rightpos )

End If

QuickSort = array

End Function