They snuck this one in there and its pretty darn cool. Deletion State Codes (DCS) are now gone in Microsoft Dynamics CRM 2011. This is a good thing and generally makes things a bit easier for developers.
First a bit of history. Since Microsoft Dynamics CRM 1.0, delete operations did not happen immediately. Instead, records where "marked for deletion" and were later cleaned up. This was originally done for two reasons:
- There was concern (think 10 years ago) that the DELETE operations were costly and could slow down the system with large amounts of data.
- Once upon a time, there was a "Recycle Bin" feature planned for Microsoft. This got cut pretty early on, but the concept of a DSC stayed around "in case" the feature found its way back in.
The clean-up operation for deletes has taken various forms over the years, originally it was a SQL Job, then it moved to a custom Windows service (The Microsoft Dynamics CRM Deletion Service), in CRM 4.0 it moved to a async operation run by the Microsoft Dynamics Asynchronous Service).
This entire feature ultimately added unneeded bloat and complexity to the system. It also made writing some custom queries and reports more complicated. This is because you had to be sure to excluded records that were pending delete.
SELECT * FROM Account WHERE DeletionStateCode = 0
The Filtered Views fortunately took care of most of this for you, but the base views and tables obviously did not.
However all was not well in the land of Filtered Views and Deletion State Codes. The filtered views did not filter out linked records that may have been pending a delete. For this reason, every CRM Lookup in a filtered view provided a "_____dsc" column. Like so:
SELECT ownerid, owneridname, owneriddsc FROM FilteredAccount
The owneriddsc (parentacountiddsc, createdbydsc, etc) would return 0 or 2 depending on whether the record was marked for deletion or not.
Anyway, the good news is that this is all gone now. While this means we won't be seeing a "Recycle Bin" feature anytime soon (auditing instead?) I think this is a good thing. Deletes now happen immediately, the tables and filtered views are simplified up and problems related to deletion jobs not running are a thing of the past.
Here is a snapshot of an account deletion operation in CRM 2011:
exec sp_executesql N'delete from [CustomerAddressBase]
OUTPUT DELETED.[CustomerAddressId], 1071
into SubscriptionTrackingDeletedObject (ObjectId, ObjectTypeCode)
where ([CustomerAddressId] = @CustomerAddressId0)',N'@CustomerAddressId0 uniqueidentifier',@CustomerAddressId0='F83AD82C-14A8-4CBE-A1A4-84C288A08C3B'
exec sp_executesql N'delete from [CustomerAddressBase]
OUTPUT DELETED.[CustomerAddressId], 1071
into SubscriptionTrackingDeletedObject (ObjectId, ObjectTypeCode)
where ([CustomerAddressId] = @CustomerAddressId0)',N'@CustomerAddressId0 uniqueidentifier',@CustomerAddressId0='D4C735D6-AFD5-473C-A90E-9F4194FEBBD1'
exec sp_executesql N'delete from [AccountBase]
OUTPUT DELETED.[AccountId], 1
into SubscriptionTrackingDeletedObject (ObjectId, ObjectTypeCode)
where ([AccountId] = @AccountId0)',N'@AccountId0 uniqueidentifier',@AccountId0='22785E42-712D-E011-B5B0-001DD8B71C42'
exec sp_executesql N'delete from [EmailSearchBase]
OUTPUT DELETED.[EmailSearchId], 4299
into SubscriptionTrackingDeletedObject (ObjectId, ObjectTypeCode)
where ([ParentObjectId] = @ParentObjectId0)',N'@ParentObjectId0 uniqueidentifier',@ParentObjectId0='22785E42-712D-E011-B5B0-001DD8B71C42'
As you can see, the cascading and related record deletes now happen immediately.
Cheers,
This posting is provided "AS IS" with no warranties, and confers no rights.
