Hi, Matt. I think Jeremy is basically taking the same approach I've been considering: events are not actually stored as "specific occurrences" except in the "events" table. The second table only contains "descriptions" of recurrence patterns involving events, but not the events themselves. The info in the second table on serves to allow creation of events.
When you say "a properly implemented recurring event pattern should also support one time events" what do you mean, specifically, by "support"? Rick -----Original Message----- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:47 AM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? I agree that you should handle recurring events by storing them as a pattern. However, I don't agree that you should store events two different ways depending on whether they are recurring or one time. As I see it, a properly implemented recurring event pattern should also support one time events. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Jeremy Allen [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 8:26 AM > To: CF-Talk > Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? > > Hello, > > We have implemented a solution at elliptIQ a couple of different ways. We > store regular calendar events in one table, and when an event has > recurrence > data we link to another table for storing the recurrence data. > > We calculate event recurrences and only store the data describing the > recurrence pattern. > > While inserting every event in a recurrence pattern certainly isn't > cheating, it isn't robust at all. We simply could not justify the > maintenance headaches that presents later on. It can be tempting to > justify > doing it the "easy" way when just storing a description of the recurrence > data and producing events for a range of dates can seem daunting. > > We have found a way (in T-SQL) to generate recurring events based on a > simple description. Eventually we will probably move to some Java > component > to handle the recurrence patterns, but for now T-SQL works. The idea is > simple. You do a self (cross) join that produces a *huge* amount of > results. > You narrow down that huge amount of results down to your recurrence rules > for one date using gigantic a gigantic where clause. There is a lot of > surrounding code for that, but the basic idea remains the same. It is not > pretty, but it worked. It should be much easier to do recurrence patterns > in > a more friendly programming language like Java. > > (FYI: We were able to implement and support the recurrence patterns of > calendar events almost exactly as Outlook does). > > > Good Luck! > > Jeremy Allen > Application Architect > elliptIQ Inc. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
