Well, the way it is set up you can specify for the event to occur only once with a recurrence pattern.
We just have a table with a 1 <-> 1 relationship with the calendar event. That could be converted to an RFC that specifies patterns in 1 field without to much difficulty. The implementation could be done a bit better since you can almost always consolidate tables that have one to one relationships into one table. (Instead of bunch of fields, it could be an RFC compliant recurrence pattern in one field). We also have it setup to modify a single recurrence of a recurring event. It can be unwieldy, but it works and it really isn't all that bad. Jeremy -----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 Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
