According to this** blog: "By design, whenever any entity metadata is changed all duplicate rules associated with that entity are unpublished."
Please, please change this design.
I'm dealing with a client now that has 9MB of -open- leads because they (seem to) constantly tinker with the Lead form and weren't aware that the duplicate detection rules weren't active.
Allow utilization of FullText indexes on specified text Fields - Specifically Activity Description fields
The current search functionality only attempts a 'contains' search on activity descriptions -
As a result, SQL Timeouts are common if the user searches the description field for a string.
It would be helpful if the application would allow fields to utilize a full-text index if available. - This could be automatic if the app could identify when an index is available and use it - or if needed, an option to configuration an attribute to 'Leverage existing full-text index' and then the DBA could create / manage the indexes that are appropriate for their environment.
I know that there is a way to remove the 5000+ restriction on views, through an unsupported modification of the DeploymentProperties table, and you probably have some reasons a to why it was introduced, but from the clients point of view, it makes no sense.
In MS CRM 4.0 clients we're complaining of the lack of a counters on view, they got it, but now they are basically all complaining about the 5000+ counter.
It should be possible to achieve a decent performance on even large tables, if not, you could consider employing a two-phase counting scheme, first rendering the 5000+ count one the view to increase response times and then update the actual count through ajax or something similar, asynchronously.
Our duplicate detection rules keep unpublishing themselves. I'm assuming it happens when a solution is deployed -> http://www.madronasg.com/blog/duplicate-detection-rules-automatically-unpublished
So my suggestion is that system automatically re-publish the duplicate detection rules when a solution is published. Or give the admin the option to automatically republish the rules.
Customers would like to have the option to export their audit logs and audit details to SQL via the Data Export Service. This would transform and make the data queryable (rather than sync the xml) allowing admins to query details of records, fields edited, and when users logged in (via the user access auditing).
This would add significant value to the auditing feature and customers who use it.
Data Export Service Cannot create a row of size 8064 which is greater than the allowable maximum row size of 8060
When attempting to sync an entity with many attributes, the initial sync or delta syncs will fail due to the sql row limit. This is a show stopper and the only workaround is to delete attributes from this entity in CRM until it's below the limit.
The underlying exception is:
Entity: publisher_entity, RecordId: dg67ce23-9e05-x311-w317-00505692015z, NotificationTime: 01/00/1900 12:15:35, ChangeType: Update, FailureReason: Cannot create a row of size 8064 which is greater than the allowable maximum row size of 8060.
The statement has been terminated.
In CRM there should be a feature to align Entity Views with the roles. Like Entity views can be seen to the user based on the security role, user belongs to. Currently, either a view is visible to all or to none (if deactivated).
When CRM SDK hits an error in the database, it throws a FaultException with the useless "Generic SQL Error" message. To debug these errors usually requires turning on SQL Server Profiler and sorting through the trace log to find the cause of the exception.
If details about the cause of the exception are available, they should be included in the FaultException object. At the very least, the exception should contain any additional details that are recorded in the CRM trace logs.
Microsoft Dynamics CRM 2013 disables the Duplicate detection rules at the start of importing the customizations but does not re-enable them whether the Import succeeds or fails.