Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Disabling Triggers

7 posts in Trigger Last posting was on 2004-10-31 08:39:13.0Z
Francois Posted on 2004-09-15 01:49:17.0Z
From: "francois" <francois@geedee.com.au>
Newsgroups: advantage.trigger
Subject: Disabling Triggers
Date: Wed, 15 Sep 2004 09:49:17 +0800
Lines: 44
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: 202.72.180.220
Message-ID: <41479e78@solutions.advantagedatabase.com>
X-Trace: 14 Sep 2004 19:44:24 -0700, 202.72.180.220
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!202.72.180.220
Xref: solutions.advantagedatabase.com Advantage.Trigger:126
Article PK: 1136194

Hi
I'm a really big trigger fan.
However having a trigger on a table can just kill performance when doing
global updates.
I urgently need some way to suppress/disable ignore triggers during a
specific update.

The following code - trimming double spaces in addresslines:

UPDATE contact SET address2=REPLACE(address2,' ',' ')
WHERE address2 IS NOT NULL
AND POSITION(' ' IN TRIM(address2))>0;

takes 300ms on 700 records with no triggers but 700s when I have a trigger
in place

Now doing this
DROP TRIGGER contactIns;
DROP TRIGGER contactUpd;
will only work if nobody else (including yourself) has the table open
somewhere.
Reinstating the triggers may also be problematic

Why not allow disabling of the trigger only for the current process?
Currently you
DROP TRIGGER - no error returned
if nobody has it open =>>>300ms action
else somebody has it open =>>>700s action
CREATE TRIGGER
which means that anybody that logged in during the 700s action will not see
the trigger until they have logged out an logged in again, but people that
remained logged in will have the original trigger working until they log out
someday!

What about
START TRANSACTION NO TRIGGERS
actions ...
COMMIT WORK
and let the developer take responsibility for his own actions.

TIA
Francois


JD Mullin Posted on 2004-09-16 22:30:59.0Z
From: JD Mullin <no@spam.com>
Newsgroups: advantage.trigger
Subject: Re: Disabling Triggers
Date: Thu, 16 Sep 2004 16:30:59 -0600
Message-ID: <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com>
References: <41479e78@solutions.advantagedatabase.com>
Organization: Extended Systems
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
User-Agent: MicroPlanet-Gravity/2.60.2060
NNTP-Posting-Host: 198.102.102.75
X-Trace: 16 Sep 2004 16:31:36 -0700, 198.102.102.75
Lines: 59
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!198.102.102.75
Xref: solutions.advantagedatabase.com Advantage.Trigger:127
Article PK: 1136193

Hi Francois,

This suggestion has been mentioned before and is on our list of future
functionality. It did not, however, make it onto the list of features we
will be implmenting for 8.0 (it just barely missed the cut).

You might want to get on the phone and pressure your sales rep or
distributor and let them know this functionality is important to you.

J.D. Mullin
Advantage R&D

In article <41479e78@solutions.advantagedatabase.com>,
francois@geedee.com.au says...

> Hi
> I'm a really big trigger fan.
> However having a trigger on a table can just kill performance when doing
> global updates.
> I urgently need some way to suppress/disable ignore triggers during a
> specific update.
>
> The following code - trimming double spaces in addresslines:
>
> UPDATE contact SET address2=REPLACE(address2,' ',' ')
> WHERE address2 IS NOT NULL
> AND POSITION(' ' IN TRIM(address2))>0;
>
> takes 300ms on 700 records with no triggers but 700s when I have a trigger
> in place
>
> Now doing this
> DROP TRIGGER contactIns;
> DROP TRIGGER contactUpd;
> will only work if nobody else (including yourself) has the table open
> somewhere.
> Reinstating the triggers may also be problematic
>
> Why not allow disabling of the trigger only for the current process?
> Currently you
> DROP TRIGGER - no error returned
> if nobody has it open =>>>300ms action
> else somebody has it open =>>>700s action
> CREATE TRIGGER
> which means that anybody that logged in during the 700s action will not see
> the trigger until they have logged out an logged in again, but people that
> remained logged in will have the original trigger working until they log out
> someday!
>
> What about
> START TRANSACTION NO TRIGGERS
> actions ...
> COMMIT WORK
> and let the developer take responsibility for his own actions.
>
> TIA
> Francois
>
>
>


Francois Posted on 2004-09-17 01:35:25.0Z
From: "francois" <francois@geedee.com.au>
Newsgroups: advantage.trigger
References: <41479e78@solutions.advantagedatabase.com> <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com>
Subject: Re: Disabling Triggers
Date: Fri, 17 Sep 2004 09:35:25 +0800
Lines: 54
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: 202.72.180.220
Message-ID: <414a3e08@solutions.advantagedatabase.com>
X-Trace: 16 Sep 2004 19:29:44 -0700, 202.72.180.220
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!202.72.180.220
Xref: solutions.advantagedatabase.com Advantage.Trigger:128
Article PK: 1136195


"JD Mullin" no@spam.com wrote in message
news:MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com...
> .... It did not, however, make it onto the list of features we
> will be implmenting for 8.0 (it just barely missed the cut).

Hi JD

I am really dissapointed.>&((
From my point of view you have a magnificent feature HAMSTRUNG by two things
1) Any GLOBAL change on a table with a trigger is going to operate at approx
1 sec per record (at leat that is what my tests have shown) if it finishes
at all.
2) You cannot reliably modify a record inside an INSTEAD OF UPDATE trigger
since you have to manually copy each and every field from the __new buffer
to the table itself.

IMHO disabling triggers on demand and autoposting the __new buffer before or
after the instead of update trigger is fired should be more important than
any other modification that you plan for Advantage. I believe that it should
be included long before 8.0 ships !!! OK I'll concede that script based
stored procedures is also important.

Very unhappy
Francois
=========<FYI==================
I believe that my suggestion
START TRANSACTION NO TRIGGERS
cannot be too difficult to implement
================================
Another way would be to implement CLEVER
triggers: That is the trigger is only fired if a field
addressed inside the trigger is modified If the
AFTER UPDATE trigger for table Trans has
the following code
================================
UPDATE TrustAC
SET Total=(
SELECT SUM(Amt) FROM Trans
WHERE AcNo=TrustAC.Account_ID)
WHERE Account_ID in (
SELECT AcNo FROM __New UNION
SELECT AcNo FROM __Old );
================================
Then it can be seen that the only fields addressed before
the final WHERE clause are Amt and AcNo. So changes
to fields Tran_date or Description etc need not fire the
trigger unless Amt or AcNo is modified as compared
between __OLD and __NEW.

It might be a bit more complicated when you have multiple
semicolon delimited statements
=========/FYI>=================


JD Mullin Posted on 2004-09-17 22:40:23.0Z
From: JD Mullin <no@spam.com>
Newsgroups: advantage.trigger
Subject: Re: Disabling Triggers
Date: Fri, 17 Sep 2004 16:40:23 -0600
Message-ID: <MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com>
References: <41479e78@solutions.advantagedatabase.com> <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com> <414a3e08@solutions.advantagedatabase.com>
Organization: Extended Systems
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
User-Agent: MicroPlanet-Gravity/2.60.2060
NNTP-Posting-Host: 198.102.102.75
X-Trace: 17 Sep 2004 16:41:39 -0700, 198.102.102.75
Lines: 61
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!198.102.102.75
Xref: solutions.advantagedatabase.com Advantage.Trigger:130
Article PK: 1136196

FYI - The ability for an AFTER trigger to update the record that the
client currently has locked IS on the 8.0 schedule. This will address
the issue of having to list out all fields in an INSTEADOF UPDATE
trigger. Instead you will be able to use an AFTER UPDATE trigger and
only modify the field the trigger is interested in.

J.D. Mullin
Advantage R&D

In article <414a3e08@solutions.advantagedatabase.com>,
francois@geedee.com.au says...

> "JD Mullin" no@spam.com wrote in message
> news:MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com...
> > .... It did not, however, make it onto the list of features we
> > will be implmenting for 8.0 (it just barely missed the cut).
>
> Hi JD
>
> I am really dissapointed.>&((
> From my point of view you have a magnificent feature HAMSTRUNG by two things
> 1) Any GLOBAL change on a table with a trigger is going to operate at approx
> 1 sec per record (at leat that is what my tests have shown) if it finishes
> at all.
> 2) You cannot reliably modify a record inside an INSTEAD OF UPDATE trigger
> since you have to manually copy each and every field from the __new buffer
> to the table itself.
>
> IMHO disabling triggers on demand and autoposting the __new buffer before or
> after the instead of update trigger is fired should be more important than
> any other modification that you plan for Advantage. I believe that it should
> be included long before 8.0 ships !!! OK I'll concede that script based
> stored procedures is also important.
>
> Very unhappy
> Francois
> =========<FYI==================
> I believe that my suggestion
> START TRANSACTION NO TRIGGERS
> cannot be too difficult to implement
> ================================
> Another way would be to implement CLEVER
> triggers: That is the trigger is only fired if a field
> addressed inside the trigger is modified If the
> AFTER UPDATE trigger for table Trans has
> the following code
> ================================
> UPDATE TrustAC
> SET Total=(
> SELECT SUM(Amt) FROM Trans
> WHERE AcNo=TrustAC.Account_ID)
> WHERE Account_ID in (
> SELECT AcNo FROM __New UNION
> SELECT AcNo FROM __Old );
> ================================
> Then it can be seen that the only fields addressed before
> the final WHERE clause are Amt and AcNo. So changes
> to fields Tran_date or Description etc need not fire the
> trigger unless Amt or AcNo is modified as compared
> between __OLD and __NEW.
>
> It might be a bit more complicated when you have multiple


francois Posted on 2004-09-18 00:39:22.0Z
Reply-To: "francois" <fransh_@westnet.com.au>
From: "francois" <fransh_@westnet.com.au>
Newsgroups: advantage.trigger
References: <41479e78@solutions.advantagedatabase.com> <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com> <414a3e08@solutions.advantagedatabase.com> <MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com>
Subject: Re: Disabling Triggers
Date: Sat, 18 Sep 2004 08:39:22 +0800
Lines: 76
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
NNTP-Posting-Host: 202.72.164.126
Message-ID: <414b8dbc@solutions.advantagedatabase.com>
X-Trace: 17 Sep 2004 19:22:04 -0700, 202.72.164.126
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!202.72.164.126
Xref: solutions.advantagedatabase.com Advantage.Trigger:131
Article PK: 1136198

That would be most welcome!
Thanks
Francois

"JD Mullin" <no@spam.com> wrote in message
news:MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com...
> FYI - The ability for an AFTER trigger to update the record that the
> client currently has locked IS on the 8.0 schedule. This will address
> the issue of having to list out all fields in an INSTEADOF UPDATE
> trigger. Instead you will be able to use an AFTER UPDATE trigger and
> only modify the field the trigger is interested in.
>
> J.D. Mullin
> Advantage R&D
>
> In article <414a3e08@solutions.advantagedatabase.com>,
> francois@geedee.com.au says...
> > "JD Mullin" no@spam.com wrote in message
> > news:MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com...
> > > .... It did not, however, make it onto the list of features we
> > > will be implmenting for 8.0 (it just barely missed the cut).
> >
> > Hi JD
> >
> > I am really dissapointed.>&((
> > From my point of view you have a magnificent feature HAMSTRUNG by two
things
> > 1) Any GLOBAL change on a table with a trigger is going to operate at
approx
> > 1 sec per record (at leat that is what my tests have shown) if it
finishes
> > at all.
> > 2) You cannot reliably modify a record inside an INSTEAD OF UPDATE
trigger
> > since you have to manually copy each and every field from the __new
buffer
> > to the table itself.
> >
> > IMHO disabling triggers on demand and autoposting the __new buffer
before or
> > after the instead of update trigger is fired should be more important
than
> > any other modification that you plan for Advantage. I believe that it
should
> > be included long before 8.0 ships !!! OK I'll concede that script based
> > stored procedures is also important.
> >
> > Very unhappy
> > Francois
> > =========<FYI==================
> > I believe that my suggestion
> > START TRANSACTION NO TRIGGERS
> > cannot be too difficult to implement
> > ================================
> > Another way would be to implement CLEVER
> > triggers: That is the trigger is only fired if a field
> > addressed inside the trigger is modified If the
> > AFTER UPDATE trigger for table Trans has
> > the following code
> > ================================
> > UPDATE TrustAC
> > SET Total=(
> > SELECT SUM(Amt) FROM Trans
> > WHERE AcNo=TrustAC.Account_ID)
> > WHERE Account_ID in (
> > SELECT AcNo FROM __New UNION
> > SELECT AcNo FROM __Old );
> > ================================
> > Then it can be seen that the only fields addressed before
> > the final WHERE clause are Amt and AcNo. So changes
> > to fields Tran_date or Description etc need not fire the
> > trigger unless Amt or AcNo is modified as compared
> > between __OLD and __NEW.
> >
> > It might be a bit more complicated when you have multiple


Stefan Overath Posted on 2004-10-29 11:01:31.0Z
Reply-To: "Stefan Overath" <stefan.overath@team-wof.de>
From: "Stefan Overath" <stefan.overath@team-wof.de>
Newsgroups: advantage.trigger
References: <41479e78@solutions.advantagedatabase.com> <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com> <414a3e08@solutions.advantagedatabase.com> <MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com> <414b8dbc@solutions.advantagedatabase.com>
Subject: Re: Disabling Triggers
Date: Fri, 29 Oct 2004 13:01:31 +0200
Lines: 100
Organization: disdatas GmbH
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: 80.133.140.182
Message-ID: <418223c2@solutions.advantagedatabase.com>
X-Trace: 29 Oct 2004 05:04:34 -0700, 80.133.140.182
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!80.133.140.182
Xref: solutions.advantagedatabase.com Advantage.Trigger:135
Article PK: 1136203

Hi!

I "disable" the trigger with an another USER...
It's not so fast like disable the trigger but you
can save time and it's a good chance to ignore
some actions on your database.

code like this:

oConn := TAdsConnection.CreateWithHandle( nil, hConnection );

if Uppercase(oConn.Username) <> 'DDMSYNC' then
begin
FreeAndNil(oConn);
exit;
end;

Hope I could help....

"francois" <fransh_@westnet.com.au> schrieb im Newsbeitrag
news:414b8dbc@solutions.advantagedatabase.com...

> That would be most welcome!
> Thanks
> Francois
> "JD Mullin" <no@spam.com> wrote in message
> news:MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com...
> > FYI - The ability for an AFTER trigger to update the record that the
> > client currently has locked IS on the 8.0 schedule. This will address
> > the issue of having to list out all fields in an INSTEADOF UPDATE
> > trigger. Instead you will be able to use an AFTER UPDATE trigger and
> > only modify the field the trigger is interested in.
> >
> > J.D. Mullin
> > Advantage R&D
> >
> > In article <414a3e08@solutions.advantagedatabase.com>,
> > francois@geedee.com.au says...
> > > "JD Mullin" no@spam.com wrote in message
> > > news:MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com...
> > > > .... It did not, however, make it onto the list of features we
> > > > will be implmenting for 8.0 (it just barely missed the cut).
> > >
> > > Hi JD
> > >
> > > I am really dissapointed.>&((
> > > From my point of view you have a magnificent feature HAMSTRUNG by two
> things
> > > 1) Any GLOBAL change on a table with a trigger is going to operate at
> approx
> > > 1 sec per record (at leat that is what my tests have shown) if it
> finishes
> > > at all.
> > > 2) You cannot reliably modify a record inside an INSTEAD OF UPDATE
> trigger
> > > since you have to manually copy each and every field from the __new
> buffer
> > > to the table itself.
> > >
> > > IMHO disabling triggers on demand and autoposting the __new buffer
> before or
> > > after the instead of update trigger is fired should be more important
> than
> > > any other modification that you plan for Advantage. I believe that it
> should
> > > be included long before 8.0 ships !!! OK I'll concede that script
based
> > > stored procedures is also important.
> > >
> > > Very unhappy
> > > Francois
> > > =========<FYI==================
> > > I believe that my suggestion
> > > START TRANSACTION NO TRIGGERS
> > > cannot be too difficult to implement
> > > ================================
> > > Another way would be to implement CLEVER
> > > triggers: That is the trigger is only fired if a field
> > > addressed inside the trigger is modified If the
> > > AFTER UPDATE trigger for table Trans has
> > > the following code
> > > ================================
> > > UPDATE TrustAC
> > > SET Total=(
> > > SELECT SUM(Amt) FROM Trans
> > > WHERE AcNo=TrustAC.Account_ID)
> > > WHERE Account_ID in (
> > > SELECT AcNo FROM __New UNION
> > > SELECT AcNo FROM __Old );
> > > ================================
> > > Then it can be seen that the only fields addressed before
> > > the final WHERE clause are Amt and AcNo. So changes
> > > to fields Tran_date or Description etc need not fire the
> > > trigger unless Amt or AcNo is modified as compared
> > > between __OLD and __NEW.
> > >
> > > It might be a bit more complicated when you have multiple
>
>


Francois Posted on 2004-10-31 08:39:13.0Z
From: "francois" <francois@geedee.com.au>
Newsgroups: advantage.trigger
References: <41479e78@solutions.advantagedatabase.com> <MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com> <414a3e08@solutions.advantagedatabase.com> <MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com> <414b8dbc@solutions.advantagedatabase.com> <418223c2@solutions.advantagedatabase.com>
Subject: Re: Disabling Triggers
Date: Sun, 31 Oct 2004 16:39:13 +0800
Lines: 128
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
NNTP-Posting-Host: 202.72.180.220
Message-ID: <4184a4c6@solutions.advantagedatabase.com>
X-Trace: 31 Oct 2004 01:39:34 -0700, 202.72.180.220
Path: solutions.advantagedatabase.com!solutions.advantagedatabase.com!202.72.180.220
Xref: solutions.advantagedatabase.com Advantage.Trigger:136
Article PK: 1136202

Hi Stefan
I have difficulty in grasping what you say!
The trigger is assigned inside the datadictionary independent of any
connection.
Even accessing the table via Arc32 still fires the trigger.

TIA
Francois

FYI:
I have one connection to a datadictionary.
The on update trigger on table1 sums the debits and credits in table1 and
updates the totals in table2
I want to do a global change on table1 like changing the processed flag to
false.
This has nothing to do with the trigger but the trigger still kicks in for
every record causing the process to continue at about 1 record per second.
If I drop the trigger it completes the full process in about 250 ms for more
than 1000 records

"Stefan Overath" <stefan.overath@team-wof.de> wrote in message
news:418223c2@solutions.advantagedatabase.com...
> Hi!
>
> I "disable" the trigger with an another USER...
> It's not so fast like disable the trigger but you
> can save time and it's a good chance to ignore
> some actions on your database.
>
> code like this:
>
> oConn := TAdsConnection.CreateWithHandle( nil, hConnection );
>
> if Uppercase(oConn.Username) <> 'DDMSYNC' then
> begin
> FreeAndNil(oConn);
> exit;
> end;
>
> Hope I could help....
>
> "francois" <fransh_@westnet.com.au> schrieb im Newsbeitrag
> news:414b8dbc@solutions.advantagedatabase.com...
> > That would be most welcome!
> > Thanks
> > Francois
> > "JD Mullin" <no@spam.com> wrote in message
> > news:MPG.1bb515bd20de800b989685@devzone.advantagedatabase.com...
> > > FYI - The ability for an AFTER trigger to update the record that the
> > > client currently has locked IS on the 8.0 schedule. This will address
> > > the issue of having to list out all fields in an INSTEADOF UPDATE
> > > trigger. Instead you will be able to use an AFTER UPDATE trigger and
> > > only modify the field the trigger is interested in.
> > >
> > > J.D. Mullin
> > > Advantage R&D
> > >
> > > In article <414a3e08@solutions.advantagedatabase.com>,
> > > francois@geedee.com.au says...
> > > > "JD Mullin" no@spam.com wrote in message
> > > > news:MPG.1bb3c2121e13293989684@devzone.advantagedatabase.com...
> > > > > .... It did not, however, make it onto the list of features we
> > > > > will be implmenting for 8.0 (it just barely missed the cut).
> > > >
> > > > Hi JD
> > > >
> > > > I am really dissapointed.>&((
> > > > From my point of view you have a magnificent feature HAMSTRUNG by
two
> > things
> > > > 1) Any GLOBAL change on a table with a trigger is going to operate
at
> > approx
> > > > 1 sec per record (at leat that is what my tests have shown) if it
> > finishes
> > > > at all.
> > > > 2) You cannot reliably modify a record inside an INSTEAD OF UPDATE
> > trigger
> > > > since you have to manually copy each and every field from the __new
> > buffer
> > > > to the table itself.
> > > >
> > > > IMHO disabling triggers on demand and autoposting the __new buffer
> > before or
> > > > after the instead of update trigger is fired should be more
important
> > than
> > > > any other modification that you plan for Advantage. I believe that
it
> > should
> > > > be included long before 8.0 ships !!! OK I'll concede that script
> based
> > > > stored procedures is also important.
> > > >
> > > > Very unhappy
> > > > Francois
> > > > =========<FYI==================
> > > > I believe that my suggestion
> > > > START TRANSACTION NO TRIGGERS
> > > > cannot be too difficult to implement
> > > > ================================
> > > > Another way would be to implement CLEVER
> > > > triggers: That is the trigger is only fired if a field
> > > > addressed inside the trigger is modified If the
> > > > AFTER UPDATE trigger for table Trans has
> > > > the following code
> > > > ================================
> > > > UPDATE TrustAC
> > > > SET Total=(
> > > > SELECT SUM(Amt) FROM Trans
> > > > WHERE AcNo=TrustAC.Account_ID)
> > > > WHERE Account_ID in (
> > > > SELECT AcNo FROM __New UNION
> > > > SELECT AcNo FROM __Old );
> > > > ================================
> > > > Then it can be seen that the only fields addressed before
> > > > the final WHERE clause are Amt and AcNo. So changes
> > > > to fields Tran_date or Description etc need not fire the
> > > > trigger unless Amt or AcNo is modified as compared
> > > > between __OLD and __NEW.
> > > >
> > > > It might be a bit more complicated when you have multiple
> >
> >
>
>