locked
The lookup reference could not be resolved - on test deployment but not on dev deployment RRS feed

  • Question

  • Hi,

    I´m getting 0x80040353 - "The lookup reference could not be resolved" error when trying to import a record into a custom entity that has a foreign key to a record in another custom entity.

    What makes this error even harder to resolve is the fact that this import works fine on my developement deployment but when I try it on my test deployment it returnes this error.

    Facts:
    1. I did change the FK GUID in the dev deployment import file before importing on the test deployment
    2. customizations.zip was exported from dev and imported onto test and published without errors
    3. I am using crm 4.0
    4. I am using my own datamap created in the wizard in Settings -> Data Management - Data Maps
    5. I am using the import wizard in Settings -> Data Management - Imports

    Does anybody have an idea about what could be causing this error?

    Hope for a quick response, Erlendur E.
    Friday, March 27, 2009 7:46 PM

Answers

  • If you never imported data maps that were created from another environment I think that the objecttypecode is probably not the origin of the problem. The data map does not contain the ObjectTypeCode and instead refers to entities by their names. However one never knows, it might be that in certain circumstances CRM emits ObjectTypeCodes in the export XML, that's why I was wondering.

    Anyway, to answer your question "anyway to make the ObjectTypeCode stay the same", this is something that I want to avoid too, and I am testing a way to do just so (I'm not yet sure it works in all cases, but until now it works perfectly):

    I create entities in a second environment in the same order they were created in the original one. The first time I am rolling out customizations in a new environment, instead than importing all customizations I import just one entity (the one with code 10001), then the one with code 10002 etc., until all entities are imported. Then I import the full customization file.

    Returning to your problem, sadly I think that there are only three possibilities:

    1. The datamap that you created on the new environment is not correct. Since you created it from scratch (and not imported it) then it might be different logically than the original one
    2. You changed the GUIDs but they are not matching the new ones after all.
    3. The error regards another field, one you are not suspecting

    You could always try to create a simple datamap with a couple of fields, take the GUID from an existing entity and create a simple file with one record a few fields and see if that works.
    Saturday, March 28, 2009 6:32 PM

All replies

  • Custom entities oftentimes have a different ObjectTypeCode from an environment to another. If you are working across environments mixing and matching data maps and importing / exporting them you might hit some obscure bug, although in theory your datamaps should not depend/rely on the ObjectTypeCode. Just a thing to check.
    Saturday, March 28, 2009 2:20 AM
  • Thanx for the quick reply.

    That is the case here.  The ObjectTypeCode is different on the dev environment v.s. the test environment.
    I thought that the import wizard would take the name of the custom entity, where used to signify a FK relationship, in the import file and find the corresponding ObjectTypeCode on the environment being used.
    Since it is not doing so where is it getting the ObjectTypeCode from?  From the datamap?  If so then the error is more peculiar than before since I did not export the datamap from the developement environment and import it to the testing environment but created it instead from scratch on the testing environment so the ObjectTypeCode should be correct in the datamap if it is present there at all.

    Are there some workarounds for this problem?
    For example:
    1. Any way to make the ObjectTypeCode stay the same in both environments?
    2. If I create all the datamaps on the developement environment and export/import to the test environment, will that do the trick?  (Since creating them on each environment as I have been doing results in the error mentioned).
    3. Is there some way of putting the ObjectTypeCode in the import file instead of the ObjectName (see below formats a and b, b is a made up format of mine that I hope is available in some sort)
    a.
    "name", "FKcustEntRecid"
    "abcd", "ObjectName_OfFKCustomEntity,{GUID_of_FK_record_in_FKCustomEntit}"
    b.
    "name", "FKcustEntRecid"
    "abcd", "ObjectTypeCode_OfFKCustomEntity,{GUID_of_FK_record_in_FKCustomEntit}"
    4. Any other workarounds ... ??

    With hope for a quick response, Erlendur

    Saturday, March 28, 2009 8:32 AM
  • If you never imported data maps that were created from another environment I think that the objecttypecode is probably not the origin of the problem. The data map does not contain the ObjectTypeCode and instead refers to entities by their names. However one never knows, it might be that in certain circumstances CRM emits ObjectTypeCodes in the export XML, that's why I was wondering.

    Anyway, to answer your question "anyway to make the ObjectTypeCode stay the same", this is something that I want to avoid too, and I am testing a way to do just so (I'm not yet sure it works in all cases, but until now it works perfectly):

    I create entities in a second environment in the same order they were created in the original one. The first time I am rolling out customizations in a new environment, instead than importing all customizations I import just one entity (the one with code 10001), then the one with code 10002 etc., until all entities are imported. Then I import the full customization file.

    Returning to your problem, sadly I think that there are only three possibilities:

    1. The datamap that you created on the new environment is not correct. Since you created it from scratch (and not imported it) then it might be different logically than the original one
    2. You changed the GUIDs but they are not matching the new ones after all.
    3. The error regards another field, one you are not suspecting

    You could always try to create a simple datamap with a couple of fields, take the GUID from an existing entity and create a simple file with one record a few fields and see if that works.
    Saturday, March 28, 2009 6:32 PM