Re: Why can't SQL SELECT's fire triggers

From: Scott Urman <surman_at_wwsun10.us.oracle.com>
Date: 8 Sep 1994 17:24:42 GMT
Message-ID: <34nhcq$m2s_at_dcsun4.us.oracle.com>


In article <34msdn$lau_at_stc06.CTD.ORNL.GOV>, ejn_at_ornl.gov (Earl Nall) writes:
|> Oracle allows triggers to be fired when issuing SQL UPDATE, INSERT and
|> DELETE, but not when doing a SELECT. I also see that this is not
|> unique to Oracle as Sybase doesn't allow this.
|>
|> What is the reasoning behind this. It seems logical to me that firing
|> a trigger from a SELECT would be beneficial in many applications (e.g.
|> access control).
|>
|> Thanks
|>
|> -------------------------------------------------------------------
|> Earl Nall Internet.ejn_at_ornl.gov
|> Martin Marietta Energy Systems, Inc. Phone....615-574-8689
|> Bldg K-1007, Rm 2260-J, MS-7058, PO Box 2003 Fax......615-241-3308
|> Oak Ridge, Tennessee 37831-7058
|> -------------------------------------------------------------------

The reason this isn't done is because triggers can do DML operations. A select statement, by its very nature, just reads the data, and doesn't change it. If you had a select trigger, than a select statement would be changing the database, which would cause problems with locking, read consistency, transaction control, etc. If you want to control access to certain data, you can do it from within the application, or by using roles. Received on Thu Sep 08 1994 - 19:24:42 CEST

Original text of this message