Comments on: How dumb the instead of triggers on MS SQL are??? http://blog.cincura.net/230777-how-dumb-the-instead-of-triggers-on-ms-sql-are/ Taking something that can't be done, and then doing it. Wed, 08 Feb 2012 15:02:30 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Alibek Kulzhabayev http://blog.cincura.net/230777-how-dumb-the-instead-of-triggers-on-ms-sql-are/#comment-3466 Alibek Kulzhabayev Fri, 16 Jul 2010 08:16:07 +0000 http://blog.cincura.net/?p=230777#comment-3466 the reason is instead of trigger works just with views that's all. the reason is instead of trigger works just with views that’s all.

]]> By: cincura.net http://blog.cincura.net/230777-how-dumb-the-instead-of-triggers-on-ms-sql-are/#comment-1692 cincura.net Sat, 25 Jul 2009 09:18:57 +0000 http://blog.cincura.net/?p=230777#comment-1692 I think, that cascade delete in FK constraint and instead of trigger on table are two not related pieces. Let's assume that my FK column allows null values. Then I can simply in trigger set it to null and the master delete operation succeeds (yes, I know I can do it directly with constraint). This scenario is perfectly valid and I'm still unable to create it. I still think it's wrong, but your comment made me realize something. I'm probably looking at the problem from more higher/design level. I see trigger as action started by database *instead of* the real operation. So the database at some level still thinks it's performing delete, but the lower level is simply throwing it away and running the trigger. Nothing more, nothing less. This architecture in my mind probably comes from the before/after trigger designs in other databases, just converted to instead of thinking. It's same with "potential" circular cascade updates/deletes. Yes I know the total shit can happen, but I'm developer, I know what I want (and if not, it's my fault, I should read something about it). Maybe the MSSQL is trying to keep me in safe boundaries too much. :) I think, that cascade delete in FK constraint and instead of trigger on table are two not related pieces.

Let’s assume that my FK column allows null values. Then I can simply in trigger set it to null and the master delete operation succeeds (yes, I know I can do it directly with constraint). This scenario is perfectly valid and I’m still unable to create it.

I still think it’s wrong, but your comment made me realize something. I’m probably looking at the problem from more higher/design level. I see trigger as action started by database *instead of* the real operation. So the database at some level still thinks it’s performing delete, but the lower level is simply throwing it away and running the trigger. Nothing more, nothing less. This architecture in my mind probably comes from the before/after trigger designs in other databases, just converted to instead of thinking.

It’s same with “potential” circular cascade updates/deletes. Yes I know the total shit can happen, but I’m developer, I know what I want (and if not, it’s my fault, I should read something about it).

Maybe the MSSQL is trying to keep me in safe boundaries too much. :)

]]> By: Petr Lazecky http://blog.cincura.net/230777-how-dumb-the-instead-of-triggers-on-ms-sql-are/#comment-1689 Petr Lazecky Fri, 24 Jul 2009 17:20:42 +0000 http://blog.cincura.net/?p=230777#comment-1689 OK, so let's assume that this will be possible. What behaviour will you expect? You are saying that "would be willing to accept the limitation when I’ll be doing there some master table manipulation". Actually you do. Your instead of trigger above is effectivelly swallowing delete in detail table meaning that if delete in master will be allowed in this case you will get orphan records in detail table on you will break data consistency. From my perspective this behaviour is quite logical as I see these two constrains contradicting each other. You either want to redirect detele operation in INSTEAD OF trigger to some other logic (usually to replace original DELETE operation with UPDATE) or you want CASCADE DELETE. If you do not want to redirect DELETE operation to some other logic (and cancelling original DELETE) you would use normal TRIGGER ON DELETE. OK, so let’s assume that this will be possible. What behaviour will you expect? You are saying that “would be willing to accept the limitation when I’ll be doing there some master table manipulation”. Actually you do. Your instead of trigger above is effectivelly swallowing delete in detail table meaning that if delete in master will be allowed in this case you will get orphan records in detail table on you will break data consistency.

From my perspective this behaviour is quite logical as I see these two constrains contradicting each other. You either want to redirect detele operation in INSTEAD OF trigger to some other logic (usually to replace original DELETE operation with UPDATE) or you want CASCADE DELETE. If you do not want to redirect DELETE operation to some other logic (and cancelling original DELETE) you would use normal TRIGGER ON DELETE.

]]>