discount furniture » Data Migration Manager Tips and Tricks

discount furniture » Data Migration Manager Tips and Tricks — Tue, 02 Sep 2008 18:08:33 GMT

PingBack from http://informationsfunnywallpaper.cn/?p=3390

re: Data Migration Manager Tips and Tricks

thomas.merli — Thu, 11 Sep 2008 15:34:11 GMT

Hi,

Let's consider the following situation:

2 source files: account, custom

account content:

GUID,NoAccount,Name

475c64f3-9de5-4883-a49c-61f5a4002c56,10000,Toto

405ad570-8ace-44f0-ae20-74762fef54d8,10001,Tata

custom content:

NoAccount,Name

10000,TotoCustom

10001,TataCustom

With the following mapping

account:

GUID -> accountid

NoAccount -> new_noaccount

Name -> name

Custom

NoAccount -> lookup on NoAccount(account,type=source)

Name -> name

Everything is fine for the parse and transform job but failed during import async job saying the specified object is not found.

Now, what I have in the temporary ParsedTable (colums: ImportDataId is a new GUID, COL0 is the id of the new entity, COL1 first col of the source file, COL2 second col, etc....). So we can see that the ID of the account is correct (this is the one we have in the source file)

account:

ImportDataId, COL0,COL1,COL2,COL3

<autogeneratedguid_1>,475c64f3-9de5-4883-a49c-61f5a4002c56,475c64f3-9de5-4883-a49c-61f5a4002c56,10000,Toto

<autogeneratedguid_2>,405ad570-8ace-44f0-ae20-74762fef54d8,405ad570-8ace-44f0-ae20-74762fef54d8,10001,Tata

custom:

ImportDataId;COL0;COL1;COL2

<autogeneratedguid>;<autogeneratedguid>;account,<autogeneratedguid_1>,TotoCustom

<autogeneratedguid>;<autogeneratedguid>;account,<autogeneratedguid_2>,TataCustom

We can see that the lookup field "account,<autogeneratedguid_1>" corresponding to the NoAccount field in the source file of the custom entity targets the guid of the importdata row (<autogeneratedguid_1) of the parsed table of the account entity.

So my problem is that the import fail with the "specified object not found" message and with additionalinfo=Account with ID=<autogeneratedguid_1> does not exists. This indicates that the import records job is looking for an account with <autogeneratedguid_1> as accountid and for sure can not find it because the corresponding account is in fact migrated with the provided GUID present in the account source file !!!!!!

Does anyone have a solution to this problem except the one to generate the lookup between custom and account entity on the provided GUID column in the source file (that I can do through SSIS but if I can bypass this step it could be nice).

In other terms, can we provide a given GUID for the accountid (or primary key field) in the source file and map related fields of other entities with account on a different source attribute than the GUID itself?

In fact, even resolving lookups on the GUID field does not work either ;((((

So it is purely impossible to migrate entities related to another entity (in the same migration process I mean, u can always migrate the primary entity with its GUID's and then migrate the related entities in a second migration step resolving lookup references in the crm system and not in the source files!!!!) if the other entity is migrated with its GUID.

The lookup resolving algorithm during the import job is just a ********* because everything in the db is present to resolve this problematic.

Instead of having "account,<autogeneratedguid_1>" in the lookup field of the data migration manager parsed table, it should use the "account,COL0" where COL0 field the id field of the entity and not the importdataid field. COL0 field is a new GUID if none is provided within the source file but if a GUID in the source file is mapped with the id field of the target entity, COL0 contains the provided GUID.

So both cases could be resolved if using COL0 instead of importdataid column which is always a newly generated id.

Does anybody know where I can post a request to the data migration tool developer teams for this suggestion????

re: Data Migration Manager Tips and Tricks

Wayne Walton — Fri, 21 Nov 2008 01:04:20 GMT

Good stuff, I'm sure I'll be coming back to this a lot.

Question, how do I make the DMM work with SQL Server 2008 Express Edition? The machine I'm using already has it on for other reasons, but the DMM wants to install SQL Express 2005 anyway.

I don't need both.

re: Data Migration Manager Tips and Tricks

Fri, 23 Jan 2009 05:20:31 GMT

I wrote my own C# code to do the data migration from .csv file to MS CRM 4.0 via CRM Webservices.

Now when I tried to migrate data into the annotation entity's NoteText attribute, I got Parsing error: “Row is too long to import". The problem is the input text field contains more than 4000 characters and the parser doesn't like it. 4000 char is the limitation a nvarchar field in MS SQL Server but the NoteText attribute is a nvarchar(Max) type.

I found a solution: http://blogs.msdn.com/crm/archive/2008/09/02/data-migration-manager-tips-and-tricks.aspx

That solution bypasses the parsing limitation when using DMM(Data Migration Manager). However for some reason I really need to data migrate using SDK directly talk to the CRM webservices. So the question is come down to how to tell the CRM webservices to stop apply the 4000 char limitation rule when I importing using SDK.

Thanks!!!