function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
VonveeVonvee 

Apex Trigger disable from SOAP

Is there any way to set an  existing Trigger to InActive from SOAP code.  We have some trigger/apex classes that will need to be refactored b/c they do not function well with Batch Update type logic -- but until I can do that -- I can disable the trigger in the GUI and continue on.   

 

This code I'm writing will be a nightly batch, so Ideally i'd like to Disable / RunData Sync / Enable said triggers all from .NET methods.  I see there's an ApexTrigger object that the Ent WSDL gives me access to, but how do i use that to find the trigger I want?  (or can i)

MartinHaagenMartinHaagen

Hi Vonvee,

 

it is possible to deactivate triggers via the SOAP API. To do this you need to use the metadata API -- however I would guess it is better to modify your triggers so that they work with batches or an alternative way could be to have the triggers not fireing for certain users/profiles (this will only work if you have a specific user for your nightly batch jobs).

VonveeVonvee

Martin -- appreciate the feedback.  I agree, long term the triggers obviously need to be adjusted to handle multi-row-transactions.  Intuitively I think people design 1-row-transaction triggers by default without considering that case since 90%+ of the time record changes run that way.

 

I had seen the suggestion too about creating a "data-load-user" and excluding it that way.  Certainly that is an easy route to do since I would just have to modify the basic trigger call .   I was about to go down that route when I discovered the reason the trigger load was truly failing had to do with "Too many SOQL statements" gov limit (b/c triggers have nasty n3 IFstatements that need to be fixed).  

 

Workaround (in case anyone is interested in the future), Temporarily I moved my batch size down from 200 to 50 and it fixed my issue.  That makes sense since the # of loops from the IF statements is proportinal to the batch size.   The trade-off is load speed.  Going from 200 to 50 doubled my load time.  But in a small data load run, this is acceptable for now.