145
Hi,
I'm a CRM newbie (but a veteran DBA) and I've gone through the forum and saw time and time again the advice not to use triggers on CRM.
I can understand the logic behind this, but - is there a way to implement a trigger on a base table without getting an annoying CRM application error ?
If not, what solution would you recommend on implementing a trace (to a trace table) updates in such entities as ContactExtensionBase ?
*This post is locked for comments
First of all - thank you all for your replies ! :)
What I need is very simple - I want to capture all updates to the ContactExtentionBase table to a seperate trace table (in another DB on the same server).
The capture should be performed only if certain columns have been updated.
Well, this is a puzzle to me as well :)
The trace table has no constraint and the datatype is correct - I've created it myself. Basically the same code (different names of course) of these two triggers behaves differently.
If I adjust the 2nd trigger (which works) to update the ContactBaseExtention table to 1 instead of NULL it still works ! but the 1st trigger does not :( I'm quite baffled at this behaviour
I forgot to mention; what you're doing is unsupported....Just an FYI in case you don't want to void your ability to request support from Microsoft....i.e. every support incident you start will begin by them having you remove all of your non-native database objects (if they accept the case).
Weird, if writing null works but writing getdate() to a Custom trace table column on a different database within the same sql instance doesn't work then I would think that was because of a constraint or data type spec on the tracetable.....I'm assuming you get the same result if you just try to flip a bit field from null to 0 or 1 on the trace table from within the trigger?
Share
Report
All responses (
Answers (
