IsNemoEqualTrue/monitor-table-change-with-sqltabledependency

Temporarily Disable Trigger/Specify fields based on action

Closed this issue · 5 comments

We have a situation where there is a time in a table that has about 35 columns that we are listening on that we need to bulk insert then update roughly 8000 records. The listener causes up to about a 10 minute delay for the user due to this. I want to know two things:

  1. Is there any way currently built in that we can temporarily disable a trigger? An example of this would be to create a temporary table in a transaction that would be destroyed when the transaction is finished where if that temporary table exists that the trigger doesn't continue...we have done this with certain unrelated triggers in the past.

  2. Is there any way to specify that we only send certain fields on Insert and Deletion vs ALL dictated fields on Update? It would be super helpful if we could tag the fields that we wanted to send with an attribute that would tell you what we wanted included in the trigger.

OR a method that would allow us to enter custom code at the beginning of the trigger would be helpful as well.

Actually that last suggestion would be even more helpful. Problem is we may want the trigger to only fire sometimes.

@christiandelbianco - I think you misunderstood my scenario. I currently have a table with 180 columns, and I have 35 columns I want to listen on - this is working as described in your documentations. Every day, I do a mass update to this table which requires an insert of 8,000 rows, and updating another 10,000 rows in a single transaction. I do not want to listen to this mass update, however it WILL update columns I want to listen on. (basically I want to do a read AFTER the fact instead of trying to receive inserts and updates on the queue for the rows I'm referring to)

However this transaction is painstakingly slow due to the table listeners. I would like to have some way to add custom code to the beginning of this trigger that would prevent the trigger from firing during this transaction.

So, would this be possible or should I fork this repo and make my own package that will allow us to do this?

@GSUFan513 Hi. You should fork the repo. Regards