Russ, And if someone accesses the data in a new way? Using PHP or .net for example? What if someone creates a stored proc? Many of our applications work with data that is "shared" in some way among applications.
-Mark -----Original Message----- From: Russ Michaels [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 11:08 AM To: CF-Talk Subject: RE: @@Identity returns excessive records Well I always put comments in the CFM pages stating that triggers will be called as a result of the query. Russ -----Original Message----- From: Mark A Kruger [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 16:55 To: CF-Talk Subject: RE: @@Identity returns excessive records I agree that triggers are A little bit more obscure than other methods of handling DB tasks. I think there IS a place for them. The afore mentioned cascading deactivation seemed to me to be a good example. I always think about 2 things when doing a trigger. 1) Make sure you document them. Triggers make it a little more difficult to pass your DB schema and design onto the next developer when you stop working with the site. They so rarely make it into the data dictionary or documentation. 2) Make sure you have thought of "additional cases" where they might fire that you had not expected. The case of directly changing data is one of them. Should you ever edit data directly? In most cases you should not. Is it ever required? Yes - sometimes it is required - so that is a case you "should" plan for, even if you have an overwhelmingly draconian policy on the matter you should plan for the case when the next guy is working with your code. In fact, as a general rule, your code and your applicaitons will definitely be seen and altered by other people down stream. You should count on it and try to make it easy on them. -Mark -----Original Message----- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:05 AM To: CF-Talk Subject: RE: @@Identity returns excessive records Not at all. I'm saying that you can use an SP to accomplish the same goals and it also secures your data and ensures the integrity you need. It is a different approach, but it is a viable and often used approach. Security is what should prevent data being changed without going through the stored procedure. That security is set on the database itself. ColdFusion has nothing to do with this discussion. - Calvin -----Original Message----- From: Russ Michaels [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:42 AM To: CF-Talk Subject: RE: @@Identity returns excessive records Then you may as well just say don't even write stored procedures either, do it all via CFQUERY. Or don't build in any relationships, let CF handle that as well. Having a trigger that detects an update and then executes the stored procedure would cover you against unforseen circumstances where the data might change without going through the SP. -- snake -----Original Message----- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 15:31 To: CF-Talk Subject: RE: @@Identity returns excessive records You can secure access to the database, limiting all updates, for example, to that SP. That should still accomplish the same goal. - Calvin -----Original Message----- From: Russ Michaels [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:20 AM To: CF-Talk Subject: RE: @@Identity returns excessive records But an SP still has to be triggered by something. And that is really what he is saying, because my example cannot be accomplished just by a SP, unless you implicitly execute that SP every time. Which means your still relying on the ColdFusion code to do so. If someone edits a record directly on the database, then how would that SP get executed. Russ -----Original Message----- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 15:07 To: CF-Talk Subject: RE: @@Identity returns excessive records That's not what he's saying. What he's saying is that an SP can accomplish the same goal. The difference is that the SP encapsulates the update and 'triggered' functionality and therefore would receive the updates instead of the table itself. Calvin -----Original Message----- From: Russ Michaels [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:01 AM To: CF-Talk Subject: RE: @@Identity returns excessive records Neil, You are totally avoiding answering the question. You have stated that an SP can do everything a trigger can do, and you have stated that an SP can automatically be execute when a certain event occurs just like a trigger. So for the 3rd time, please show me how. russ -----Original Message----- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 14:38 To: CF-Talk Subject: RE: @@Identity returns excessive records What you are stating and what the process is are two different beasts.....your trigger is simply a lazy way to monitor a process which you are not doubt firing as part of what I would assume is a cfquery. Why don't you just throw that update into an SP and handle the whole shebang in the SP? You would have the original status and the new status and the success of the process. Anything a trigger can do, normal SQL can do (almost anyway ;-) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215660 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
