When there is a need of converting local to global optionSet we can use https://xrmoptionsetconverter.codeplex.com/. Everything works fine until this customization needs to be exported to another environment on which local optionSet is already declared and filled with data.
Why?
While importing customization error occures: OptionSetId cannot be changed. EnumAttributeInfo.AttributeDescription.OptionSetId(xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) != xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx;
How does the tool really works?
Basically it takes local optionSet, creates its temporary copy to which all current data, views, forms are beeing copied. Local optionSet is being deleted. Then destination global optionSet is being created and new local option set with same name are original is created and all data is being copied back.
But
There is always some “but”.
First of all when tool creates new attribue CRM WCF creates not only new AttributeId but also new ColumnNumber (it is used in audit). Despite new local optionSet (which indicates to global optionSet) has same schema name it is treated as completely new attribute. Also audit mechanism doesn’t know what to do with new fields – so it throws exception while exploring.
Solution
Another option is to:
1. Create global optionSet at eg. DEV environment and export it to LIVE/STAGE/TEST
2. Find it’s quid and
3. UPDATE Attribute SET OptionSetId = ‘NewGlobalOptionSetGUID’ WHERE AttributeId = ‘LocalOptionSetGUID’
This operation provides all data specified in audit because ColumnNumber has not changed 🙂
Your solution obviously only works in an on premises environment. Universally, If the tool is ran in dev, you can’t export and import into another environment until you run the tool in the environment you are importanting into.
Sure – it is the only way to avoid audit columnNumber changing.
Solution was thought to work when you already have LOC in every environment and want to convert into GOS.
I’ll have to also research if column number is something that can be set via the SDK calls…
@Daryl: As far as i am concerned it is not possible. Once attribute is createdthe column number (which is being used in audit) cannot be changed – just like it’s schema name.
Anyway please let me know if I am wrong.