anything you can do to stop workload on CF is great, therefore i think triggers would be a great option for this that aside here are some of the costs involved:
Performance impact - Triggers have to write to one or more local tables that act as audit trails. With moderate or heavy transaction volume the performance degradation increases. Consolidation of the audit trail - A trigger instruments one database server and writes an audit trail on the local machines. But monitoring multiple servers and consolidating the audit trail in a central repository is difficult to do correctly with triggers. Incomplete coverage - A trigger can only capture data changes - UPDATE, INSERT, DELETE. Triggers cannot capture changes to schema and object permissions. Maintenance burden - Like any other program, once triggers are correctly written, they must be maintained. Triggers are tightly coupled to the structure of a table, so each time the table schema changes, the trigger code must be rewritten. Complexity - Adding more triggers to address auditing requirements increases complexity of the environment, leading to a higher probability of bugs and incorrect logic. HTH REF: http://wapurl.co.uk/?743R18A On 25/05/06, Ken Ferguson <[EMAIL PROTECTED]> wrote: > We have CFCs which handle all of our crud operations on form data. What > we do for auditing is to call the corresponding function from the > auditing component before making any updates or deletes. This > essentially inserts all of the data from the rows that a user is about > to update/delete prior to the operation. These audit tables also have > columns dedicated to tracking the user information... It seems to work > pretty well. Be careful though, as this can be a very resource-intensive > task if you're auditing changes for a lot of data in a high-traffic > environment. > > ******************************************** > Ken Ferguson > 214.636.6126 > [EMAIL PROTECTED] > > I'm currently in the market for any available project work. > Experience, knowledge and strong references I can > certainly provide. > ******************************************** > > Tony wrote: > > thats what i do. > > > > on the edit page loading, i set the original values into hidden fields, and > > then > > sense a change, if there is any change, i write all the new values to > > the database. > > > > tw > > > > On 5/25/06, Dave Francis <[EMAIL PROTECTED]> wrote: > > > >> Or you can keep the original values in hidden fields, and compare them > >> against the input fields when they submit. Saves a db access. > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, May 25, 2006 1:28 PM > >> To: CF-Talk > >> Subject: RE: Tracking changes to a database > >> > >> I had the same issue with a form I was having people fill out with pre > >> entered data. > >> > >> The logic after I filled out the form was that I would check each entry > >> against the current data. If it was different, I would put it into a > >> "Changelog" table. > >> > >> Then I would do an update. > >> > >> Original Message: > >> ----------------- > >> From: Les Irvin [EMAIL PROTECTED] > >> Date: Thu, 25 May 2006 10:42:24 -0600 > >> To: [email protected] > >> Subject: Tracking changes to a database > >> > >> > >> What's the preferred concept in tracking database changes? > >> > >> For example, let's say there are 3 fields in a database. A user can go in > >> and edit one, two, three, or none of the fields. How can I track what was > >> changed and what was not? > >> > >> Thanks in advance, > >> Les > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:241516 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
