Allowing an exception to a trigger

I created an UPDATE trigger on a table - but there one case where I would not the trigger to occur. I mean, in one procedure it may update this table and I would not the trigger to occur a update occurred because of this stored procedure. I could alter my trigger but I am not sure if I would be able to tell which procedure caused it without adding a special column, but if I have to I will.

Hello Echo88,

Echo88:

I created an UPDATE trigger on a table - but there one case where I would not the trigger to occur. I mean, in one procedure it may update this table and I would not the trigger to occur a update occurred because of this stored procedure. I could alter my trigger but I am not sure if I would be able to tell which procedure caused it without adding a special column, but if I have to I will.

A short answer is, yes, you would solve this with an additional column.

A slightly more detailed answer would be, check your "architecture" because your access paths here are "imbalanced". I mean, it sounds like sometimes you directly write to the table, sometimes you write through the stored procedure. My advice is go with stored procedures only. Great chance is your trigger's logic here really belongs to its own procedure which you would call instead of straight writing to the table.

Hope this makes sense. -LV

|||

Thanks for the advice. All writes to any table are done through stored procedures, except triggers because I need to access the trigger tables, but I do it for code maintenance reasons - it just simply easier for to pack it up that way.
Anyway, I am not in love with adding columns after my "architecture" has already been established and I found a better to handle the conditional update. I remember that MS SQL handles UPDATES by placing the new row in the INSERTED trigger table and the old row in the DELETED. I simply just compared the two rows and obtained the results I needed.