DA Morgan wrote:
> Tony Rogerson wrote:
>> Like I said, the public documentation is here:
>> http://msdn2.microsoft.com/en-us/library/ms130214.aspx;
>>
>> Like I said, you've lost all objectivety and are 100% blinded by bias.
>>
>> An example is the triggers - you state no equiv to before statement,
>> when in fact you don't actually do real statement triggers...,
>
> So if you don't think this is a statement trigger then tell me precisely
> what it is?
>
> CREATE OR REPLACE TRIGGER test
> BEFORE UPDATE
> ON orders
> DECLARE
> vMsg VARCHAR2(30) := 'Trigger Fired';
> BEGIN
> dbms_output.put_line(vMsg);
> END statement_level;
> /
>
> If I update 1 row in the table it fires once.
> If I update 1,000,000,000 rows in the table it fires once.
>
> Stop, for a second, throwing mud and do something constructive.
> Tell me what this trigger is?
>
> And while you are doing that read this:
> http://download.oracle.com/docs/cd/B14117_01/server.101/b10759/ap_standard_sql001.htm
>
>
> Look I don't want to play some game with you but please take a second to
> review what I do for a living. You can't baffle me with BS so if you
> want to make a point do some research and learn something about the
> subject.
>
> There is one part of the ANSI definition of statement level triggers
> that Oracle doesn't support ... that being the :OLD and :NEW tables.
> That does not make the trigger something other than a statement level
> trigger. I am trying very hard to take you seriously but so far you've
> done little to support that proposition.
Will the trigger fire if no row is updated?
A statement trigger should (because the statement executed)
It is my understanding that in Oracle a statement trigger is a
row-trigger than fires only for the first row...
Not taking sides here btw. SQL Servers INSTEAD OF triggers on tables are
just a workaround for before triggers and I'd love to see how a SQL
Server statement trigger performs row-actions when the primary key was
updated (lining up those INSERTED and DELETED rows may prove
difficult...). Having to do a JOIN on the transition tables to get to
rows is just nastily inefficient and can be outright wrong.
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Received on Tue Aug 21 2007 - 22:40:37 CDT
