1. Added 0 and 1 as supported Submit Options
2. Fixed issues with converting .AddOption to .addOption method.
3. Conversion alerts were added for the following JavaScript properties:

• .title
• .vAlign
• .contentEditable
• .innerText

1. Any .style property that is not either display or visible is now marked as a conversion issue. This is to help identify instances where people have created unsupported code which will probably not work within the CRM 2011 environment.
2. The use of document.all.mnuBar1 now produces a conversion alert.
3. Instances of the DOM element ‘Notifications’ will cause a conversion alert will be generated. This is a special CRM form element at the top of each data entry form that shows alerts to the user. For more information on using this technique, see this article.

You may download the new package here.

Normally, people access a form field using the following style of JavaScript:

crmForm.all.name

This is the normal and perfectly acceptable (and supported) method for referencing CRM form fields.

But, for various reasons, I’ve also seen fields reference using these crmForm methods:

crmForm.name
crmForm.elements["name"]
crmForm.all["name"]
crmForm["name"]

This is perfectly acceptable JavaScript and the CRM 4.0 object model had no objection to this practice, so all of these methods seemed to work.

In fact, accessing CRM form fields using the JavaScript document object using these methods worked as well:

document.all(“name_c”)
document.all["name"]
document.getElementById(“name_c”)

The real question is: Will these methods continue to work when the organization is upgraded to CRM 2011?

The answer is: If you have used standard and supported methods within your JavaScript, then yes, the code will be supported.

This means referencing all of your form fields using the standard access model:

crmForm.all.name

Other options may or may not work correctly. Your experience my vary depending on which of the above methods were used.

Fortunately, the CRM Migration Assistant converts all of these “unsupported” form field access types into fully-supported CRM 2011 code using Xrm.Page.getAttribute and Xrm.Page.getControl, depending on how the field was being used.

If you haven’t already, download the trial version of the CRM Migration Assistant and convert some of your questionable JavaScript through the conversion process.

If you run into any conversion issues, send me a code sample so that I can update the conversion process.

Many of the techniques we used in CRM 4.0 were technically unsupported.  But since work had to be done, we did stuff like that anyway.

As part of the migration process we actually convert many forms of unsupported, and supported, code into their supported CRM 2011 equivalents.

Here are a few of the basic conversions that you can do:

Tabs

crmForm.all.tab0Tab

Xrm.Page.ui.tabs.get(0)

crmForm.all.tab1Tab

Xrm.Page.ui.tabs.get(1)

crmForm.all.tab2Tab

Xrm.Page.ui.tabs.get(2)

crmForm.all.tab3Tab

Xrm.Page.ui.tabs.get(3)

crmForm.all.tab4Tab

Xrm.Page.ui.tabs.get(4)

crmForm.all.tab5Tab

Xrm.Page.ui.tabs.get(5)

crmForm.all.tab6Tab

Xrm.Page.ui.tabs.get(6)

crmForm.all.tab7Tab

Xrm.Page.ui.tabs.get(7)

Global Variables and Methods

ORG_LANGUAGE_CODE

Xrm.Page.context.getOrgLcid()

ORG_UNIQUE_NAME

Xrm.Page.context.getOrgUniqueName()

SERVER_URL

Xrm.Page.context.getServerUrl()

USER_LANGUAGE_CODE

Xrm.Page.context.getUserLcid()

GenerateAuthenticationHeader()

Xrm.Page.context.getAuthenticationHeader()

Form Properties and Methods

crmForm.ObjectId

Xrm.Page.data.entity.getId()

crmForm.ObjectTypeName

Xrm.Page.data.entity.getEntityName()

crmForm.Save()

Xrm.Page.data.entity.save()

crmForm.SaveAndClose()

Xrm.Page.data.entity.save('SaveAndClose')

crmFormSubmit.crmFormSubmitId.value

Xrm.Page.data.entity.getId()

For more information on how the CRM Migration Assistant can help convert your JavaScript, visit our product page.

I’ve seen a few customers change the the format from the default, First Name Last Name, to Last Name, First Name.  This allows you to Contacts and Leads sorted by last name.

The Issues

This is very effective, but here are some issues:

• when performing a quick search ( typing in a name in the search box at the top of a view ), you must enter the full name as Last Name, First Name, instead of First Name Last Name. For example: Smith, Bob instead of Bob Smith.  This is usually counter intuitive to most users.

• Mail Merge operations can no longer use Full Name as a field. You must use the First Name and Last Name fields.  Otherwise, the person’s name will be displayed in reverse order.

Those are just a couple of things to keep in mind when you start changing the default system settings.

Please let me know if you have any comments or have found additional issues.

Preparing for CRM 2011: How to Make your Microsoft Dynamics CRM 2011 Upgrade Faster

Run the deletion service. In CRM 4.0, if you deleted records, the records were not immediately deleted-they were flagged for deletion, then the CRM deletion service came along, usually within 24 hours, and deleted the records.

One problem that can happen, especially if large numbers of records were bulk deleted, is that records can get stuck in the “soft delete” state.

In 2011, there is no more soft deletion of records-they are deleted immediately from the database when the records are deleted in CRM. When you upgrade, the upgrade process will hard delete any leftover “soft deleted” records. If you have many deleted records in your system, this step can take a while.

Before you upgrade, you may want to search your main entity tables to identify if you have a large number of soft deleted records still sitting in your database. For example, the following query will identify any deleted records that still exist in the account tables:

select * from accountbase where deletionstatecode = 2

If you find that there are high volumes of deleted records still residing in the database, you can clean them up with a free tool such as Mitch Milam’s "Run CRM Deletion Service" utility.

Sorry Joel, but it was something I forgot to put on my own list and just too good not to repost.

You need to consider removing all of these additions prior to the upgrade.

The pre-upgrade validation checks will give you a warning that unsupported things exist and the installation may actually fail, depending on the changes you made.  And as noted by an article, item #3,  from Customer Effective, the error message may not be very clear as to what the problem is.

Just a word of warning.

Like the AsyncOperationsBase table containing old and useless information, these tables present the same sorts of issues.

Luckily, the Microsoft UK Dynamics Support team has an answer:

Script to clean up SyncEntry_<GUID> and SubscriptionStatistics_<GUID> tables in the SQL database

There are some slight modifications to make the script run better, as outlined in an article from Customer Effective on the same subject:

Clean Up Old Synch Tables In Your Microsoft CRM Database

Again, this is a SQL operation so if you are not comfortable with SQL, the please find someone who is.

Regardless of current system performance, an abnormally large number of records in this table can slow down the upgrade process.  Since we want our upgrade to go as smoothly as possible, it would be a great idea to clean out as much data as you can.

Here are some tools that will help you clean up records that are no longer needed:

• The Workflow Expansion Task records cause the AsyncOperationBase table in the MSCRM database to grow too large in Microsoft Dynamics CRM 4.0
• The AsyncOperationBase and WorkflowLogBase tables grow very large and performance issues occur when you use many workflows in Microsoft Dynamics CRM 4.0

Note:

These articles give you SQL scripts to run so you really need to be comfortable with SQL operations before attempting them.  If you are not, then please find someone who is.

Finally, most of these operations can affect the entire system so you may need to run them after normal business hours.

Additionally, here are a couple of tools that I have found that may be of use.  I’ve not used either in a production environment so if you have questions, please contact the people who wrote them before putting them to use.

• CRM Automatic AsyncOperationBase Delete Tool
• Bulk Delete Launcher

I’ll try and dig into these utilities more in-depth in a later article.

You may download the trial version here.

Navigation Element Conversion

The conversion of navigation elements ( navActivities, navActivityHistory, etc. ) was initially added to convert code like this:

var myvar = document.all.navOpps.style.display;

into this:

var myvar = Xrm.Page.ui.navigation.items.get("navOpps").getVisible();

An issue was discovered where we were improperly converting in certain cases. Take this example:

var navContracts = document.all.navContracts;
var navCases = document.all.navService;
var navInvoices = document.all.navInvoices;
if (navCases != null) { navCases.style.display = "none"; }
if (navContracts != null) { navContracts.style.display = "none"; }
if (navInvoices != null) { navInvoices.style.display = "none"; }

will now convert into this:

var navContracts = Xrm.Page.ui.navigation.items.get("navContracts");
var navCases = Xrm.Page.ui.navigation.items.get("navService");
var navInvoices = Xrm.Page.ui.navigation.items.get("navInvoices");
if (navCases != null) { Xrm.Page.ui.navigation.items.get("navCases").setVisible(false); }
if (navContracts != null) { Xrm.Page.ui.navigation.items.get("navContracts").setVisible(false); }
if (navInvoices != null) { Xrm.Page.ui.navigation.items.get("navInvoices").setVisible(false); }

The issue revolves around the fact that the developer used the name of the navigation element as the variable name to hold a reference to the DOM element.  In the case above, the code is correct and will function correctly, but a redundancy was created.  And unfortunately, there is no really good way around this – besides not naming your variable names the same as pre-defined DOM objects – because this:

navCases.style.display = "none";

Is a perfectly legal JavaScript statement for hiding a form navigation element and the conversion process has no clear way to determine if you are using a variable or an object reference name

Navigation Group Identifier Alerts

Occasionally you will find CRM JavaScript where someone is manipulating the group headers of the form navigation area. In CRM 2011, they look like this:

CRM 4.0 has similar groupings, but with a different style of triangle. They have IDs like:

• _NA_SFA ( for Sales )
• _NA_CS ( for Service )
• _NA_MA ( for Marketing )

A conversion alert is created if any identifier that begins with "_NA_" is found.  While this type of code may still work in CRM 2011, you may wish to seek alternatives.

More information is available here.

Release Notes

This month’s release focused mainly on enhancements to the conversion process.

Bug Fixes

• Corrected an issue that produced an error when connecting directly to CRM 4.0 to extract customizations.

• Corrected an connection string issue when publishing to CRM 2011 via Internet Facing Deployment ( IFD ).

• Fixed incorrect conversion of:   

var result = document.all("name").style.visibility;
to
var result = Xrm.Page.getAttribute("name").getVisible();

• Fixed issue where, in certain cases, the internal CRM onload JavaScript event was being selected instead of user-defined onload JavaScript event.

• Corrected improper conversion of SetRequiredLevel and setAttrbute(“req”,x);

• Corrected an issue with the Picklist.DefaultValue conversion.

4.0:      crmForm.all.new_mypicklist.DefaultValue = 2;
2011:     Xrm.Page.getAttribute("new_mypicklist").setValue(2);
4.0:      var result = crmForm.all.new_mypicklist.DefaultValue;
2011:     var result = Xrm.Page.getAttribute("new_mypicklist").getInitialValue();

Enhancements

change0() Method

This is an undocumented and unsupported CRM method sometimes used by developers. This now gets converted to .fireOnChange.

Additional Toolbar IDs Added

Added “_MS” and “ISV_” to the list of toolbar control IDs which will generate a conversion warning.

.value

.value is not supported in the same way as .DataValue.

Example:

crmForm.all.name.value = crmForm.all.line1.value;
Xrm.Page.getAttribute(\"name\").setValue(Xrm.Page.getAttribute(\"line1\").getValue());

document.all now converts like crmForm.all

Example:

document.all.name.value = document.all.line1.value;
Xrm.Page.getAttribute(\"name\").setValue(Xrm.Page.getAttribute(\"line1\").getValue());

[IFRAME].url now converts like [IFRAME].src

Added support for Partially-qualified Field Names.   

Example:

crmForm.name.DataValue;
Xrm.Page.getAttribute("name").getValue();

Modified conversion to treat: crmForm.elements like crmForm.all.

Added conversion issue notes for:

• AddParam
• additionalparams
• lookuptypeIcons
• lookuptypes
• setAttribute(“defaulttype”, “2″);
• onabort
• onblur
• onchange
• onclick
• ondblclick
• onerror
• onfocus
• onkeydown
• onkeypress
• onkeyup
• onload
• onmousedown
• onmousemove
• onmouseout
• onmouseover
• onmouseup
• onreadystatechange
• onreset
• onresize
• onscroll
• onselect
• onsubmit
• onunload
• areaActivityHistory
• areaActivities
• crmNavBar
• mnuBar1

If raw Navigation Items are found, they are converted:

navAsyncOperations.style.display = "none";
Xrm.Page.ui.navigation.items.get("navAsyncOperations").setVisible(false);

if (document.all.navSubConts != null)
if (Xrm.Page.ui.navigation.items.get(\"navSubConts\") != null)

Added conversion alert for non-standard try/catch block at the end of the event.

Reduced the conversion time by 50%.