We currently have a test CRM installation that we want to use the GUID's for
the account and contacts in other systems. (as a unique identifier) Since
this is a test system and we would like to go to a production system soon,
can we keep the GUID's the same on the new production environment as they are
on the test environment.

Thanks,

-Zac

Hello,

Some time ago I was playing around with the CRMService.Create function. I
first manually created a new account instance. And next I manually assigned
an accountid to it, using a GUID I created myself. So I guess when you use
the SDK this should be fully supported. (And this is the only way...)

However I don't like being dependent on the internal GUID generated by CRM.
For example if you would like to recreate an account, you are always bound to
the SDK to get it done. So I used a text field of 38 positions to store the
old guid. Kind of surrogate key.

Best regards,

Merijn van Mourik
http://crmerijn.blogspot.com

"Zac Anderson" wrote:

You "could", but are you really saying that you are porting data from your
test system to production? That seems odd since, by nature, test data is
suspect.

The SDK allows you to supply the GUID when you create records though.

--

Matt Parks
MVP - Microsoft CRM


"Zac Anderson" <zanderson@crmdiscussions.microsoft.com> wrote in message
news:0564A738-F13C-401F-980F-C6A910190585@microsoft.com...
We currently have a test CRM installation that we want to use the GUID's for
the account and contacts in other systems. (as a unique identifier) Since
this is a test system and we would like to go to a production system soon,
can we keep the GUID's the same on the new production environment as they
are
on the test environment.

Thanks,

-Zac

I was just playing with this yesterday, and my results support Merijn
- by setting the .accountid and .contactid to keys with values set for
the Guids, you could specify the guid used to create an account or
contact.

I'd recommend against this, and actually go through the motions and
create accounts and contacts manually using the process you've already
defined as a test on your production environment that everything
operates correctly. If you put data in that you know works, then you
learn nothing from that - and it can confuse people as to why some
data works and some doesn't if things go wrong.

--Kris Rhodes
CRM 3.0/VB.NET developer
Quantum Business Technology
Perth, West Australia

On Mar 21, 4:54 am, Merijn van Mourik
<MerijnvanMou...@discussions.microsoft.com> wrote: