Scope of DISABLE TRIGGERS FOR LOAD

Posted by gdickson on 04-Nov-2014 09:15

Recently saw some code that defined an internal procedure and the purpose of the internal procedure was to disable triggers for load  and then to update some fields that would normally be updated by the trigger code.

That internal procedure can get called pretty early in the main procedure. Or not.

What is the scope of the disable triggers for load statement? Is the statement limited only to the internal procedure (what the programmer intends) or do the triggers remain disabled from the point in time that the internal procedure is called?

Thanks!

All Replies

Posted by TheMadDBA on 04-Nov-2014 09:33

Scoped to that internal procedure and anything called from that internal procedure.

Not 100% sure this holds true for internal procedures called in persistent/super procedures.

Developer still deserves a slap for doing this though :)

Posted by gabriel.lucaciu on 04-Nov-2014 09:53

As an update on your first question on "the scope of the disable triggers for load":

Disabling triggers for LOAD disables all triggers associated with the CREATE, WRITE, REPLICATION-CREATE, REPLICATION-WRITE, REPLICATION-DELETE, and ASSIGN events for the named table.

Posted by gabriel.lucaciu on 04-Nov-2014 09:55

As for the second question:

Triggers disabled with the DISABLE TRIGGERS statement remain disabled for the duration of the procedure in which you issued the statement and any subprocedures.

Posted by Marian Edu on 04-Nov-2014 10:02

allow-replication can be used to let the replication ones alone...

On 04.11.2014 17:53, gabriel.lucaciu wrote:
>[collapse] From: gabriel.lucaciu
> Post: RE: Scope of DISABLE TRIGGERS FOR LOAD
> Posted in: Forum
> Link: http://community.progress.com/community_groups/openedge_development/f/19/p/14069/50400.aspx#50400
>
> As an update on your first question on "the scope of the disable triggers for load":
> Disabling triggers for LOAD disables all triggers associated with the CREATE, WRITE, REPLICATION-CREATE, REPLICATION-WRITE, REPLICATION-DELETE, and ASSIGN events for the named table.
>
>
> --
> You were sent this email because you opted to receive email notifications when someone created a new thread.
>
> To unsubscribe[collapse] from:
> - ...only this thread, disable notifications at http://community.progress.com/community_groups/openedge_development/f/19/p/14069/50400.aspx#50400.
> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>
>


--
m.edu
keep it simple
http://www.ganimede.ro
http://ro.linkedin.com/in/marianedu
medu@ganimede.ro
mobile: +40 740 036 212
skype: marian.edu[/collapse][/collapse]

Posted by gdickson on 04-Nov-2014 11:57

The internal procedure (where the DISABLE TRIGGERS FOR LOAD) is used, is being passed the table in question as a parameter. Currently the trigger only updates three fields, a date, time, and code.

The thinking is that under certain conditions, those three fields need to be set differently than how the trigger would set them. This is the same table that is being updated by the calling procedure. Maybe that is obvious, but just to be sure...

So are the triggers only disabled for the subset of time that the internal procedure is executing (it calls no other procedures), or are the triggers disabled from the point in execution of the statement, through the end of the internal procedure AND the end of the calling procedure?

We are having discussions about better ways to implement what the business requested, but we are in a "if it ain't broke, don't fix it" kind of state.  I am just trying to be sure it ain't broke, before we push it into production.

Posted by TheMadDBA on 04-Nov-2014 13:19

A better way would be for the trigger to decide based on the data what to do (or make a business object and get rid of the triggers completely).

Really this is easy enough for you to test... but it only disabled during the scope of that internal procedure.

/*--- Triggers active here ---*/

RUN SomeIP. /*--- triggers disabled in SomeIP ---*/

/*---- Triggers active again ---*/
assign table.field = "ABC".

PROCEDURE SomeIP:
 disable triggers for load of table.
END.
 

This thread is closed