Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2022 Release Wave 2Check out the latest updates and new features of Dynamics 365 released from October 2022 through March 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
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 ?
It depends on what you're trying to accomplish, typically we would build a .NET plugin and subscribe to the appropriate events based on what was needed. If your scope is SQL and you really need to get this done then you could build a sql job to poll the table using the last modified date > last job execution to get a list of records which have been changed. You could cause SQL deadlocks with this approach depending on your setup though (even with(nolock)) so you will want to monitor that. For that reason, I would use Filtered views (all core + extension tables are combined in View objects that begin with the word Filtered and in their definition use nolock; other views do not consistently provide nolock)
Well, since I'm a DBA my scope is the SQL :)
I've tried using an AFTER UPDATE DML trigger that simply writes the changes the the table using the INSERTED table.
I've written a seperate DML trigger on the same table which simply updates certain columns with NULL and it works like a charm ! but my first trigger simply causes the CRM to put out an error each time I try to update (from the CRM app of course).
I can't understand why the first trigger causes an error while the 2nd trigger works fine :(
I've tried to trim down the trigger - simply to write the timestamp into a trace table each time there's an update ... same mysterious CRM app error.
Any ideas ?
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?
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).
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
And yes, I'm aware of the lack of support issue. That's why I'd rather stick to SQL :)
Can I perform this trace using a workflow / plugin ?
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.
Yes, thank you. I'll investigate the matter further. :)
Business Applications communities