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 ;-)














~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Find out how CFTicket can increase your company's customer support 
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215626
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

Reply via email to