Trying to figure out just how your approach would be implemented... You're suggesting one table for everything?
And I can't get my brain around an implementation that would handle your approach: >For example, suppose you created an implementation to support patterns >like, "the first day of every month from 1/1/97 to 1/1/98." The former >is a recurring pattern, but could easily be turned into a one time event >by thinking of it as, "the first day of every month from 1/1/91 to >1/1/98." Wouldn't that pattern have to be turned into specific occurrences at some point? Rick -----Original Message----- From: Matt Liotta [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:06 PM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? For example, suppose you created an implementation to support patterns like, "the first day of every month from 1/1/97 to 1/1/98." The former is a recurring pattern, but could easily be turned into a one time event by thinking of it as, "the first day of every month from 1/1/91 to 1/1/98." While it may seem silly to describe even one time events using a similar pattern to recurring events, it does give a system a single way to deal with events, which IMHO, it enormously valuable. Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: Rick Faircloth [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 11:53 AM > To: CF-Talk > Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? > > 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4