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!
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 :)
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.
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.
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]
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.
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.