locked
CRM 2011 Online. Option set name doesn't match when importing solution RRS feed

  • Question

  • We have a prospect on a CRM Online trial.  We've done some customisations and deployed the solution.  After some feedback we've made further modifications inside the solution and tried importing that newer version but get hit with the following error...

    Option set name (qg_account_qg_servicecontract) doesn't match with the one from existing option set (qg_servicecontract_account).

    I found someone else had the same issue...

    http://social.microsoft.com/Forums/en/crmdevelopment/thread/7984ec10-0510-4406-a515-0f01077fcb67

    but I am trying to deploy to Online and obviously have no control over the rollups.  I doubt Online hasn't got the rollup installed.  It does... doesn't it?

     

    Friday, May 27, 2011 7:26 PM

Answers

  • MS Support sorted me out.  There's a SQL script they provided that I ran on the solution source db. Rebuilt the solution from scratch and was good to go.  It's a known issue.  Something to do with one of the sides of the story being a system that was upgraded from RC.  If both systems started life as final release code, then this problem doesn't occur.

    I'd contact them if I were you.

    • Marked as answer by Jim Glass Jr Tuesday, September 20, 2011 8:46 PM
    Thursday, August 25, 2011 8:02 AM

All replies

  • Hi,

    Before importing customizaiton, you can open the OptionSet attribute qg_servicecontract_account  in CRM online and can delete the options or either change them as same you have in the system form where you have exported the customizaiton file.

    I hope this helps and please mark as answer if it helps.


    Thank You,
    Jehanzeb Javeed,
    http://worldofdynamics.blogspot.com
    Linked-In Profile |CodePlex Profile

     If you find this post helpful then please "Vote as Helpful" and "Mark As Answer".


    Friday, May 27, 2011 9:51 PM
  • Hi,

    I am experiencing same issue - but on premise installation. We installed rollup on both dev and demo versions, and I am getting same error:

    "Option set name (new_incident_new_complainttype) doesn't match with the one from existing option set (new_complainttype_incident)."

    Changing option set name manually before customization is not the way to go, as during next import you get an error on another option set - it looks like name of all custom option sets differs.

    Looks like I would have to get rid of manage solution at all and start with fresh solution install.

    Jan

    Monday, May 30, 2011 7:59 AM
  • Partial success.  That worked for the OptionSet above, but is now failing on a Two Options attribute (Yes/No).  That hasn't changed and is identical in both systems.  I've deleted that field from target so it will be sucked in on the installation of the new solution.  Lucky this is a trial rather than live instance!

    The above action has meant that the account entity goes through successfully.  But I'm now failing on another Option Set field on the Lead entity.  I've edited the target system so the values match that in the solution but I'm still failing with an error message similar to the above.

    This is turning into a bit of a showstopper for the customer.  Any further ideas out there?

    Wednesday, June 1, 2011 11:23 AM
  • I have the same problems on Microsoft Online (currently with Rollup 3) and our development environment (Rollup 3, too). We are not able to import customizations into CRM Online. The errors are still the same (Option set name (ortex_media_account) doesn't match with the one from existing option set (ortex_account_ortex_media), .... it is a Two Options attribute in fact). After deleting the field in the target system we move only a little step ahead - to a next custom attribute. But there are hundreds of custom attributes! That's why we are using solutions and solution import/export feature, aren't we?

    Any idea what to do?


    Jan Vanek http://www.crmexpert.cz
    Thursday, August 25, 2011 7:50 AM
  • Hi, same problem here with CRM Online. I've opened a case with Microsoft but still no luck...any idea?
    Thursday, August 25, 2011 8:01 AM
  • MS Support sorted me out.  There's a SQL script they provided that I ran on the solution source db. Rebuilt the solution from scratch and was good to go.  It's a known issue.  Something to do with one of the sides of the story being a system that was upgraded from RC.  If both systems started life as final release code, then this problem doesn't occur.

    I'd contact them if I were you.

    • Marked as answer by Jim Glass Jr Tuesday, September 20, 2011 8:46 PM
    Thursday, August 25, 2011 8:02 AM
  • Hi John, still no success here contacting Microsoft...any chance you can email us the sql script Microsoft gave you? thanks!!
    Thursday, August 25, 2011 8:26 AM
  • I'm actually on holiday.  I'll have a go at finding the script if you can provide me with your email address but I can't promise I'd be able to get it to you before next week sometime.  My email address is firstname dot lastname at the same domain address as our website.

    Without wanting to state the obvious... you're on your own with the results of the script. Back everything up before hand and I'll deny all knowledge of this conversation ever taking place ;)

    • Proposed as answer by rajais Tuesday, September 20, 2011 11:53 AM
    Thursday, August 25, 2011 8:38 AM
  • hi john, could you please give me the script as well even I am facing the same issue.

    My email address is rv_266463@hotmail.com

    Any help will be Highly appreciated !!!

    Tuesday, September 20, 2011 11:56 AM
  • Hi John, today the same problem occurred on a different CRM online organization....I'm very puzzled!! This organization is a production environment of a customer of ours...and Microsoft support doesn't provide any solution about this issue!

    May you please send to me the script as well? My address is filippo.bertelli@4edu.it.

    Thank you very very much for your help!

    Anyone solved this issue?

    Filippo

    Tuesday, September 20, 2011 7:33 PM
  • Hi John,

    We have the same issue please send to shayha@sitqad.co.il the script with some guidness if you can :)

    Thanks

    Wednesday, October 19, 2011 9:21 AM
  • Hi John,

    can you send me these Script.

    Thx!

    Thursday, October 27, 2011 7:27 AM
  • Hello,

    Can someone explain me why this problem happened?

    I talk with microsoft support last week, and since then they didn't fix the problem...

    John, how much time it take MS to send you the script? because I think it's specaily for your organization.

    Thanks

    Thursday, October 27, 2011 8:12 AM
  • The script was sent to me while I was on the phone with them.  They didn't ask for any particulars of my systems and I have since successfully used the same script on another organisation.  So I'm pretty sure it is generic.
    Thursday, October 27, 2011 8:44 AM
  • Here's the script.  Use at your own risk.  If it goes horribly wrong, on your own head be it.  I was reluctant to post a MS Support provided script up here and I expect this post may be taken down by a moderator but I am being asked for this script on a regular basis (there's another similar thread elsewhere).  I don't know why some of you are having difficulty with MS support on this issue.  For me they were pretty helpful.  The script has worked for me on 2 separate organisations.  If it doesn't work for you, there may be something else awry.

    -- This script is for all intents and purposes supposed to match the script ApplySchemaNamePrefixToOptionSets.sql
    
    declare @DefaultPublisher uniqueidentifier = 'D21AAB71-79E7-11DD-8874-00188B01E34F' 
    declare @SchemaNamePrefixLowerCase nvarchar(9) -- the prefix is 8 characters plus 1 for the underscore
    
    select @SchemaNamePrefixLowerCase = LOWER(CustomizationPrefix collate Latin1_General_CI_AI) + '_' from Publisher where PublisherId = @DefaultPublisher
    -- The first thing we will do is change the naming convention of custom picklist and boolean option sets
    -- on system entities.  This is to address bug 122849.  In order to be more assured that these option sets
    -- are created with a consistent name no matter what organization the option set belongs to and the name
    -- has a valid prefix it is easier to start these names with the attribute name rather than the entity name.
    -- These names are also guaranteed to be unique since all attribute + entity name combinations must be unique.
    -- NOTE:  Because we're dealing with custom option sets on system entities, we can eliminate the State and Status
    -- attribute types because if a system entity has State and Status they will be OOB attributes and the names will
    -- be set through the metadata XML, and customizers cannot add custom State or Status attributes to a system entity.
    update o set o.Name = LOWER(a.LogicalName + '_' + e.LogicalName collate Latin1_General_CI_AI)
    from MetadataSchema.OptionSet o
    join AttributeView a on a.OptionSetId = o.OptionSetId
    join EntityView e on a.EntityId = e.EntityId
    where o.IsGlobal = 0 
    and o.IsCustomOptionSet = 1
    and a.IsCustomField = 1
    and a.AttributeTypeId in ('00000000-0000-0000-00AA-110000000030', '00000000-0000-0000-00aa-110000000013')
    and e.IsCustomEntity = 0
    
    -- Now see if after changing these names for custom picklist and boolean option sets on system entities if any
    -- do not have a proper prefix - those will need to be corrected
    declare @OptionSetId uniqueidentifier
    declare @OptionSetNameOld nvarchar(123)
    
    -- Retrieve list of Custom Local OptionSets that are used by Custom Attributes of System Entities and don't have Schema Name prefix set already.
    -- The check for whether there is a prefix is based solely on whether we find an underscore someplace between characters 3 and 9, inclusive, as that
    -- is the main component of what the ValidateSchemaNamePrefix code does in the MetadataService.  If it is a custom attribute with such a prefix
    -- we can be confident the other checks (must start with a letter, must not equal "mscrm", etc) were checked when the attribute were created.
    DECLARE optionset_cursor CURSOR LOCAL FAST_FORWARD FOR
                   select o.OptionSetId, o.Name from OptionSetView o
                   join AttributeView a on a.OptionSetId = o.OptionSetId
                    join EntityView e on a.EntityId = e.EntityId
                    where CHARINDEX(N'_', SUBSTRING(a.LogicalName, 3, 7)) = 0
                    and o.IsGlobal = 0 
                    and o.IsCustomOptionSet = 1
                    and a.IsCustomField = 1
                    and a.AttributeTypeId in ('00000000-0000-0000-00AA-110000000030', '00000000-0000-0000-00aa-110000000013')
                    and e.IsCustomEntity = 0
    
    OPEN optionset_cursor
    
    -- Loop through each of the OptionSets that must have its name changed
    FETCH NEXT FROM optionset_cursor INTO @OptionSetId, @OptionSetNameOld
    while (0=@@FETCH_STATUS)
    begin
                    declare @SuffixAsInt int = -1
                    declare @SuffixAsNVarchar nvarchar(123) 
    
                    -- Make sure the length of the new name does not exceds 123 and it does have enough space for the prefix
                    declare @OptionSetNameNewNoSuffix nvarchar(123) = @SchemaNamePrefixLowerCase + SUBSTRING(@OptionSetNameOld, 1, 123 - LEN(@SchemaNamePrefixLowerCase))
                    declare @OptionSetNameNewNoSuffixLength int = LEN(@OptionSetNameNewNoSuffix)
                    declare @OptionSetNameNew nvarchar(123) = @OptionSetNameNewNoSuffix
    
                    -- Make sure there is no existing OptionSet that has this new name already.
                    -- If the name exists already then append a numeric prefix to the new name until we get a unique new name
                    while (exists (select * from OptionSetView where LOWER(@OptionSetNameNew collate Latin1_General_CI_AI) = LOWER(Name collate Latin1_General_CI_AI)))
                    begin
                                    set @SuffixAsInt = @SuffixAsInt + 1
                                    set @SuffixAsNVarchar = CAST(@SuffixAsInt as nvarchar(123))
    
                                    -- Make sure the length of the new name does not exceds 123 and it does have enough space for the suffix
                                    set @OptionSetNameNew = SUBSTRING(@OptionSetNameNewNoSuffix, 1, 123 - LEN(@SuffixAsNVarchar)) + @SuffixAsNVarchar
                    end
                    
                    -- Set the new name to the OptionSet
                    update MetadataSchema.OptionSet set Name = @OptionSetNameNew where OptionSetId = @OptionSetId
                    
                    -- Move on to the next OptionSet that must have its name changed
                    FETCH NEXT FROM optionset_cursor INTO @OptionSetId, @OptionSetNameOld
    end
    
    CLOSE optionset_cursor
    DEALLOCATE optionset_cursor
    
    go
    

    Good luck.  I'm off to hide in the shadows.

    Thursday, October 27, 2011 10:23 AM
  • Thanks again John, but our test enviroment is crm 2011 on premise and the production is crm 2011 online.

    Where I need to run this script? I can't run it in the online...

    Thanks

    Thursday, October 27, 2011 12:20 PM
  • My scenario was the same. So I just ran the script against our development, on-premise database through SQL Management Studio, then rebuilt the solution.  You have to rebuild the solution from scratch.  Simply exporting the existing solution again won't do it.  Create a new solution and put the components in.
    Thursday, October 27, 2011 1:21 PM
  • Hi John,


    I have a doubt why at all the naming conventions for the Picklists/ Two options differ from one organization to the other??

    Monday, June 4, 2012 6:26 AM