Lynn Pettis (3/16/2013)

---

brettstahlman (3/16/2013)

---

Lynn Pettis (3/16/2013)

---

brettstahlman (3/16/2013)

---

opc.three (3/16/2013)

---

The reason why I disagree is because of the behavior of the after trigger when it is the instead trigger that is fired first. The instead trigger fires the after trigger, but even if the after trigger does something that should fire the original instead trigger on the same table, it does not fire regardless of the values of the nested or recursive settings.

In your case the after trigger fires first, but similar to the case I just described it will not fire an instead trigger on the same table regardless of the values of the nested or recursive settings.

Maybe the documentation has a hole in it, it certainly would not be the first time, but the behavior seems to be predictable and consistent. Just my two cents.

I'm not arguing that it's not predictable and consistent in the instance of SQL Server I'm currently running... But the same could be said of just about any bug in a specific instance of software. My point is that the only sort of predictable behavior we should rely upon as developers is that which can be predicted from the specification, and there is nothing in the spec indicating that the instead of trigger will not be invoked from an after trigger on the same table. Are we in agreement?

No.

A good example of changes made by MS that comes to my mind is the WebTasks procedures. Fully documented and useable without special permissions. Then one day MS decides to change that behaviour in a SP and code that worked for many people suddenly broke. IIRC, this change wasn't even communicated prior to it being implemented. What does this have to do with this discussion? Everything.

This is why you do regression testing when applying CU's, Service Packs, upgrades; to make sure that the behaviour of your code hasn't changed unexpectedly and with possible disastrous effects to your data. From what I have been reading, you are expecting 100% perfection in the MS documentation. Good luck with that.

I'm not sure why you said "No": I asked whether the previous poster agreed that the behavior and documentation were inconsistent; far from contradicting my assertion, you provided another example of this sort of inconsistency, and even seemed to be implying that I should ignore the spec, relying upon rigorous testing instead. Even if the spec is so unreliable as to make this a reasonable approach, it should be pointed out that you haven't contradicted my basic assertion. Recall that I didn't say a developer shouldn't test his implementation. Testing is necessary, but not sufficient. Additionally, the implementation should not rely upon undocumented "features", even if they seem to work consistently. As a general rule (your WebTasks example notwithstanding), such features are more likely to change in a non-backwards-compatible way than spec-conformant behavior...

The "No" may have been a misinterpretation of what I had read. With that, I apologize.

What I spoke of was not an inconsistency, it was a significant change in behaviour of a well documented capability at the time. It was changed without any notice.

What I am saying here is that you need to perform full regression testing on your application when applying CU's, service packs, or upgrades in you development and QA environments prior to applying them in production. This is needed to ensure that demonstrated behaviour (that which you currently expect and have seen) doesn't change and cause problems. If it does change, then you need to determine what changes you need to do to make to correct the problem.

I would say you need to do this even if the documentation was 100% accurate now. There is nothing to say MS might not making changes that could change behaviour in ways you may not anticipate, and do so without much fanfare (if any at all).