Removing Old Migrations from Data Migration Manager

You may get to the point where you have performed a number of migrations with the Data Migration Manager (DMM) - test and/or production.

You may have experienced that a bulk deletion or import gets longer with each migration as your total data in the MSCRM_MIGRATION database (which is either going to be in the SQL Database you specified during the install of DMM or on a local SQL Express instance) increases.

You may also have experienced a small inconvenience where all your migrations have to have a unique name.

All that is needed to get around this small problem is flushing ouu the ImportBase table in the MSCRM_MIGRATION database.

USE MSCRM_MIGRATION;

DELETE FROM ImportBase;

File Too Large for CRM Data Map

To produce a demo of a CRM system, I was trying to use some data from an Access system and suck it up into CRM using the Import Data Wizard. I'd created my queries and tables in Access and exported the data out into a .csv file using the Export Wizard in Access.

With this .csv file (it originally had 2,100 or so records) I tried to create a Data Map for my import. I selected my .csv file to use as the Sample Data for my map. Naturally CRM complained that this file was too large to be used as the sample. I deleted some of the records from my file, leaving about 50 rows, and then tried again. I was still getting the error though. My file size was only around 200kb, well below the 4mb limit that CRM has for file uploads by default (this can be changed in the web.config for CRM). I didn't have very many columns, maybe 50 at the most.

I should point out I was using Excel 2007 to edit my .csv files, and Access 2007 generated the file.

I thought that 200kb was large for what was in the file; just 50 rows of data like I mentioned.

What ultimately fixed it was this (although I don't know why).

1) I opened my original .csv file in Excel.

2) Deleted the rows I didn't want.

3) Clicked Save (I got a prompt about losing formatting if I saved it to a .csv file, and I clicked yes I wanted to continue).

4) Closed the document

5) when I got a prompt asking if I wanted to change the file, I clicked yes.

In earlier attempts I had been clicking no, because I'd already manually performed the save process after I removed my rows. I didn't think I needed to do it again.

After clicking yes to perform this second save on exit, my file size shrank considerably and CRM had no issue with the sample 50 rows of data. I am not sure if there were some artifacts in the file from Access creating it or if Excel was changing the file in the second save in a way that a manual save was not. All I know is that this worked. I can't say that it'll fix every problem relating to .csv files being too large for an import, but there's no harm in trying it.

The Given Key Was Not Present In The Dictionary

There've been a few times I've come across this error with CRM when writing small plug-ins, more as a test exercise than anything to use in production - yet.

It's always the same scenario too. You write your plugin, maybe a Create message or an Update message, you check the code and you register the DLL and a step. You come to test it, and you get a pop-up with the not so helpful text of "The given key was not present in the dictionary".

At first I found the message very confusing, but I eventually found an explantion for why it was happen (or at least had a vague grasp of the problem that was causing it).

When ever you reference an attribute of a Dynamic Entity, you are using a key/value pair. The key is the name of the attribute, the value is obviously the value of that attribute and a container which holds key/value pairs is called a dictionary.

The error is down to referencing an attribute name that is not available in the dictionary you are looking at. There may be a number of reasons for this, but I think the most common two are: 1) The key (attribute name) has been mistyped in the code; or 2) It's not available in the current message.

I've had this happen in Update Message plugins, because in an Update Message the Dynamic Entity containd in the Target property of the context's InputParameters only contains the attributes on the entity which have changed. If the user did not change the name of the account before they pressed save then "accountname" is not going to be present in an Update Message.

I hope that makes sense, but there's a chance it wont, because like I said I'm still trying to grasp the finer points of it, especially when it comes down to using the InputParameters and the Target property. They are something I've seen in many plug-in tutorials and copied down as gospel, but not really taken the time to sit down and find out what it's for.

Hopefully this post will get you past an error and make you sit down and find out what's actually going on with your context properties too.