Dynamics CRM World!!: 2013

Saturday, October 5, 2013

Dynamics CRM 2013 is available in CRM online now!!

Dynamics CRM 2013 is available for online trial now!

Click here to grab a 30 days CRM 2013 online trial

CRM 2013 SDK available for dowload!!

SDK 2013

Saturday, September 14, 2013

MS Dynamics CRM Report Error "Report Does not exist"

Today i came across and error that saying "Report Does not exist. The error came when i try to delete the report from the Dynamics CRM reports section.

We had moved the current CRM instance to a new domain, with new organization name. There comes the issue!! We imported the organization database CRMORG_MSCRM, but after the testing we came across this error for all the scheduled reports.

During the investigation we found that the Reporting server is almost empty with no scheduled reports available. but the OOB and SSRS reports are working fine. i tried to delete the report from CRM Reports section, but couldn't do so only Error came up!!

Now comes the resolution part, The issue is because the Scheduled reports are stored in the ReportServer Database, which was not imported. So we need to somehow delete the reports and reschedule the reports, In the report server the Reports are stored in the Report-server->Organization Name->4.0 folder with the GUID of the report schedule as name in the Report server, we need to trick CRM by uploading a dummy report file (.rdl) and rename the Report to the GUID of the Scheduled report. The Report GUID can be found by clicking f11 button and copying the GUID from the URL. Use the Guid with "{GUID}" in the name of the uploaded RDL, now we can delete the Report form CRM Report section. Viola!!!! Reports are deleted!

I have tested the above scenario and it is working fine!! for further queries u drop a mail Contact me

Saturday, September 7, 2013

Few Use full links for Microsoft Dynamics CRM, that u will never wanna miss!!

What's new in Dynamics CRM 2013 Latest News!!

No More Entity Base & Entity Extension Base Tables!!!

So that means faster execution of Reports, views, & Limited SQL & CRM usage when working with Filtered views!! this will be a great improvement in the performance of CRM 2013.

Here is the blog from

Source

As a consultant who spends a lot of time with the data in CRM I’ve always wondered if the <entity>ExtensionBase tables would persist forever as they were really there because of a limitation of SQL 2000. However since Microsoft no longer supports SQL 2000 or 2005 with Dynamics CRM and with the reliance on 64 bit hardware, the sky is really the limit. I am excited to say that as of CRM 2013, there will no longer be <entity>Base and <entity>ExtensionBase tables; they will be merged and it will just be <entity>!

CRM 2011 and Earlier Configuration: Default and custom fields stored in separate tables.
<entity>Base ie. AccountBase – Holds OOTB data elements and key information for the entity
<entity>ExtensionBase ie.AccountExtensionBase – Holds all custom fields you’ve created and added to the entity. This requires an extra key in the database to store that relationship between the base entity and the extension.
CRM 2013 Configuration: One table per entity. All fields are merged
Why does this matter?

Fewer Joins
Fewer Locks
Higher efficiency in queries and views
Streamlined design
Less data overhead
Redundant keys are removed

How do I merge these tables?
The process is handled by the upgrade, however Microsoft has indicated that you will be able to defer the merge of these tables for a period of time but Dynamics CRM 2013 will still continue to work with both models. So, if you have some custom stuff happening in your database, Plug-ins or in Scribe (integration) jobs or maybe some Data Warehouse loading/Extract Transform Load jobs, you’ll need to consider your plan for making these work with the new merged table structure.

Hooray, merged tables, what else is coming with 2013?
How about easily embedding Yammer into your application, including specific group conversations?
Broad HTML 5 Support
Newly designed form flow
New navigation
Stage Gating on multiple entities
Advanced authentication (some really neat stuff here)
Access Teams (These are really cool!)
Enhanced mobility features and access
Outlook client enhancements

Why should'nt we Direct T-SQL Update on a CRM Database Solid Reasons from Microsoft MVPs!!

Jamie Miley

If you are using Auditing in CRM, it won't reflect any changes done by manual database update.

Modified, by, modified on, etc... will also not be adjusted properly

PrincipleObjectAccess table will not be updated based on manual updates and so permissions will not be properly set on any inserted, updated, deleted records.

Scott Sewell

Database updates to CRM, if you did updates to something that affects security (owner, business unit, etc...) no updates would occur to PrincipleObjectAccess table

Updating Name fields will cause issues because lookups tend to cache names

Damian Sinay:

Plugins and/or workflows won't fire

Also caching is an issue, any cached data won't be invalidated by a database operation.

Gustaf Westerlund

If you are not 110% sure what youa re doing you are risking the stability of the entire system.

Julie Yack

It’s bad karma to do unsupported stuffs when a supported way will do it.

Carston Groth

Relations might get lost if you´re only performing the action on one datebase table ignoring all related tables

Joel Lindstrom

Biggest reason is that it will appear to work initially but problems will crop up later and you won’t be able to connect the dots to the real issue because the issue won’t be caught by the normal error reporting mechanisms.

Example:

Customer manually loaded contact records and later couldn’t reassign them. Turned out to be because in their manual load they didn’t populate businessunitid. The contacts worked, but couldn’t be reassigned later because that field wasn’t populated, but the error message generated didn’t explain what the problem was, because records created in a supported way always have that field populated

Different customer manually overwrote the createdby and modifiedby using unsupported T-SQL. Records initially appeared to work OK; however, when users attempted to forward the message in CRM, they got an error. Again, since this was a delayed error situation that showed up months later, it was very difficult to find the real reason for the error—all diagnostics did not show the real problem.

So to me, that is the biggest reason not to create records in an unsupported way. It is very difficult to verify that it is correct because standard system data validation does not fire, and if you miss anything, the real problem may not show up for months and will most likely be outside of the normal error reporting mechanism. You are on your own. Was it worth it?

In Conclusion

In the end, I think these are all great ideas regarding the issue. I really just want to echo Gustaf above. The fact is that it is considered unsupported for a reason. Microsoft doesn't want to deal with it either. All unsupported customizations are adding serious risk to your entire implementation as Microsoft would be entirely within their right to wipe their hands of the entire implementation when they can show that these types of things are being used. The API and SDK are there for a reason, please use them. There are ways to do almost anything you could be trying to do that would cause you to go an unsupported route. This is where a good partner can really steer you in the right direction. You have already invested a lot of money on your Dynamics CRM implementation in software costs and in most cases consulting time to put it into place and get it customized properly, protect that investment!

Source

Saturday, August 17, 2013

CRM 2011 Email Attachment - Sharepoint Archieval

After a very long gap.. back to the blog writing.. this time with a solution to all the CRM implementations who are having trouble with their Database Size.

In one of the projects i worked we came across a situation where the Database is at the threshold level, and the analysis showed that the 75% of the Database is taken by the Email Attachments. which constitutes most of the space. and the business need is such that we couldn't delete old emails to get relieved of attachments.

The Solution came up was to use Share point!!!
yes! share point is the best solution to store documents and attachments which could store the attachments storage and we can give the link of the storage folder to an Iframe in the Email form.

Below is the link to the solution developed by me for archiving the email attachments to SharePoint folders.
CRM 2011 Email Attachment to SharePoint archival

It is a Codeplex link, try to solution and let me know for any issue in here or in the codeplex discussions or issues tab

Friday, January 4, 2013

CRM Reports Error Subreport could not be shown

Follow the steps mentioned below (take a look at the last point).

First run sub-report individually without calling from main report. If it show output means there is no error in sub-report.
If 1st step execute successfully, then for time being disable or delete sub-report and run main report, Check weather if it shows output successfully.

If you fail in 1st step means there is some problem in sub-report.
If you fail in 2nd step means sub-report is working fine, problem with main report.
If 1st and 2nd step run successfully then make sure you have pass parameter properly between reports.
If Pre filtering is enabled in your reports delete the Default filter of modified on last 30 days filter in both main report and sub report.

Dynamics CRM World!!