locked
CRM 4.0 BUG? Extra prefix added on Customization Import RRS feed

  • Question

  • I have created several new entities, attributes, and relationships within CRM 4.0.  Most of my relationship names look something like "prefix_entityName_prefix_entityName."  I have built a new CRM 4.0 environment from the ground up and attempted to load my customization file.  Everything loads successfully but I noticed that the relationship names for our custom entity relationships now have an extra prefix added to it.  The relationship names now look like "prefix_prefix_entityName_prefix_entityName."  All of the entity names and attribute names are fine but for some reason CRM is appending whatever prefix that is defined in Settings to the relationship names during import.  This is a problem because now this new environment is out of sync with our customization file.  Any changes we want to load from our customization file in the future will now fail since these relationship names are out of sync.

    I have also tried to upgrade to Update Rollup 2, exported the customizations, built a new environment, upgrade to Rollup 2 and imported the customizations but I get the same result.
    Monday, January 26, 2009 5:47 PM

Answers

  • I have finally determined the issue after a lot testing and mucking with the customization file.  Come to find out, the determining factor for whether or not the CRM Import process appends a prefix is based on the length of the prefix in the customization file!

    If the prefix length is two characters (SW, SL, AB) the import process will append another prefix (defined in your CRM settings) to your custom relationship names during the import process.

    If the prefix length is greater than two characters (New, Test, ETC) the import process will import the relationship name as is without the extra prefix.

    I'm working with Microsoft about getting some sort of resolution to this, in a Hotfix or Rollup because this is obviously a pretty serious issue.
    Thursday, January 29, 2009 11:36 PM

All replies

  • I don't think this is a bug. It look like it does this by design. The point of the prefix is so you (as a developer) is aware who (which ISV or developer) has done what customization to the system.

     

    An example:

    1. Some developer has created an entity with a schema name "yha_entity1" (their prefix is yha)
    2. Then you create another entity with a schema name "new_entity2" (your prefix is new)
    3. Now when you create a new relationship between these entities it adds your prefix plus the two entity schema names.

    So

     

    "new_" (because you are adding a new customization) +

     

    "yha_entity1" + "_" + "new_entity2"  (existing schema names)

     

    = "new_yha_entity1_new_entity2"

     

    There may be a problem with your development environment (maybe a different or much earlier version of CRM), what you describe should work.

     

    Your customizations should move like so: Development ---->Testing ---->Production.

     

    Never develop or fix in testing or production environments, otherwise you lose version control.

     

    Hope this clears things up.

    Thursday, January 29, 2009 4:32 AM
  • If this is by design then the whole Development -- Testing -- Production will not work.  That's why this is such a big problem.  When you have a customization file and you import it into another environment, CRM should not be appending anything to your customizations.  Since they seem to be doing that, then your Development -- Testing -- Production will have different relationship names and your customizations and are out of sync.  I'm not sure how this could be by design.

    All environments are CRM 4.0 and none of them were upgraded from 3.0.
    Thursday, January 29, 2009 2:29 PM
  • Not that I doubt you but, I've done this many times into VPC "sandboxes" and twice into the production server and I don't see that phenomena.  I have yet to apply either rollup.

     

    And a word to the wise-

    NEVER create an attribute in two different places.  They are keyed on GUID's (yes, kids, a huge violation of relational model theory, but what can you expect from guys who are stuck on hierarchical data) and the collisions will corrupt your database -- permanently as far as I can tell.

     

    Also watch out if you change an attribute in Dev.  You should delete the downstream counterparts before applying the customization for the same reason.

     

    Thursday, January 29, 2009 10:24 PM
  • I have finally determined the issue after a lot testing and mucking with the customization file.  Come to find out, the determining factor for whether or not the CRM Import process appends a prefix is based on the length of the prefix in the customization file!

    If the prefix length is two characters (SW, SL, AB) the import process will append another prefix (defined in your CRM settings) to your custom relationship names during the import process.

    If the prefix length is greater than two characters (New, Test, ETC) the import process will import the relationship name as is without the extra prefix.

    I'm working with Microsoft about getting some sort of resolution to this, in a Hotfix or Rollup because this is obviously a pretty serious issue.
    Thursday, January 29, 2009 11:36 PM
  • Hi, John

    I have this problem with 2 char prefix. Did Microsoft resolve this problem?
    Monday, April 6, 2009 7:56 AM