I ran into an issue about a week ago where I was completely unable to get custom context-filtered reports working in my CRM environment. I created an extremely simple test report, since I figured the issue may be due to the complexities of the original report that I was having issues with, and could not get the report to work in my test environment or any other environment that I tried. Microsoft Support has resolved the issue and here is what happened:
I had restored a backup of our production CRM database on a test server to use for an internal development project. The original database was called Summit_Group_Software_MSCRM and I restored it as Summit_Group_Software_Test (notice the missing _MSCRM). Aparently CRM detects a report as being a “CRM” report based on the _MSCRM suffix in the connection string, so without that, CRM thought my report was some random report not tied to a CRM datasource. Therefore, CRM does not modify the report in any way, including the queries (which is how context sensitive filtering is enabled) or the connection string. I had also noticed that the connection string was not getting updated however I was not too concerned about it since I was developing the report in the same environment that I trying to use it in.
There are a couple of resolutions to this problem:
- Take a backup of your database, restore it with _MSCRM at the end of the database name, and import your organization
- Before uploading the report into CRM, open the report in Notepad or another text/XML editor and modify the database name in the connection string to have _MSCRM at the end of it.
I opted for option one since it is just a development system with nothing else tied to the database and since it would get annoying to continually need to use option two while I design several other reports. The implementation guide probably states that databases must be restored with a _MSCRM suffix but I did not bother checking.
The _MSCRM suffix was more import than I would have ever dreamed…