Skip to main content

Notifications

Dynamics 365 Community / Forums / Finance forum / BPErrorEDTNotMigrated
Finance forum
Suggested answer

BPErrorEDTNotMigrated

editSubscribe (1) ShareShare
ReportReport
Posted on by 118
Hi,

I got this BP warning below in my entity staging table:

BPErrorEDTNotMigrated: The relation under the extended data type (EDT) 'XYZ' must be migrated to table relation. Consider using EDT relation migration tool.   
 
1. Is it enough to just create a new relation?-- as the BP warning disappears once i add it
2. As In some places, i read that we need to add the relation, in addition to mark /ignore EDT relation/ on the staging table field as true, is this needed?
3.  And some said, we need to add the relation, in addition to filling /source EDT/ on the relation itself, is this needed?
4. when copying the relation from the actual table to the entity staging table, do i need to remove the /onDelete/ property and the index property?
5. on the relation, there is a property, called /EDT Relation/ do i need to change this one to true or false? 
 
  • CU04051814-0 Profile Picture
    CU04051814-0 118 on at
    BPErrorEDTNotMigrated
    Hi Andre,

    1. I got confused now, so for fixing the BP warning is adding the relation enough? or do i need to set "ignore Edt relation" to yes as well?
     
    3. So you think it's not important? currently i'm copying it's value from the original relation table, if it's yes i leave it as yes, if it's no i leave it as no

    6. For cardinality and related cardinality , i understand it for regular tables. But when i copy the same relation from the original table to the staging table, do they need to change?
    For example, in the article you sent me, it said cardinality on sales line for salesId is zero more, and related cardinality is exactly one, which makes sense.

    Now let's say i created a single entity with SalesLine inner joined SalesTable.
    Now on the staging table, for salesId relation

    Would cardinality stay as zeroMore?
    Would related cardinality stay as exactly one?
    if yes, are there cases where they need to be different than the original relation?
  • Andre Arnaud de Calavon Profile Picture
    Andre Arnaud de Cal... 283,375 Super User on at
    BPErrorEDTNotMigrated
    Hi,
     
    When replying the first time, I didn't check the details in Visual Studio. For the relations on staging tables, you can set a property named validate. With this property you can manage if you allow non-existing values in staging tables. When copying to the target, the values, like a valid customer account number should be verified. I don't know where or when the IgnoreEDT on field level is used. I never looked at that detail myself.
     
    3. Thanks for the clarification. You can have a look at the CustTable as an example where it is filled for the Currency relation, but not for CustDirectDebitMandate. I haven't checked it recently, but from what I remember, the EDT relation migration tool did manage the property value.
     
    4. I missed a part of your question, I noticed now. For foreign key relations, you should not remove the index value.
     
    5. See my reply to question 3. As far as I remember this property was managed by the migration tool for review purposes only. The value itself doesn't have any impact on the functionality.
     
    6. As there are thousands of data entities, I don't know the answer. You can have a look at e.g. the next blog to learn more about the cardinality: Table cardinality explained – DynamicsFox
     
     
     
     
  • CU04051814-0 Profile Picture
    CU04051814-0 118 on at
    BPErrorEDTNotMigrated
    Hi Andre,

    1 and 2 : So you think i should do both add relation and set ignore EDT to true, right?
    but i didn't understand your explanation in point 2, about the importance of setting ignore EDT as true to all staging table fields and not just the ones with BP warning? what do you mean by  "If you don't allow incorrect values, loading the data in the staging table will be blocked."  How would i not allow incorrect values by setting ignore EDT as false?
    Do you mean that if there is a legacy EDT relation let's say on custTable, and i tried to import a customer account that doesn't exist in the table, if ignore EDT relation was false, then no data will be inserted into staging table and the whole import will be blocked? but i would still see the error to know the reason?. However, if ignore EDT relation was true, then the wrong custom account would have appeared in staging table as i will see the error and i could have edited the value on the staging table itself instead of re-importing? and other correct values would have been imported already?
     
    3. I mean, some say to solve the BP warning, we need to add the relation and fill this "source EDT" property as well when we specify the fields relation -- do you think this is needed?
     
    4. You answered me about the "onDelete" property that i need to remove it but not the "indexProperty". Because we normally copy the relation on the table itself to save time, so if those values were filled, do i need to remove them both? or just the onDelete?
    ​​​​​​​
    5. If the original table relation, already has this "EDT Relation" as Yes, shall i change it to No as well in my staging table?
    Also what does it mean? why do we have ignoreEdt on the field, and we have this property on the relation here? what's the difference

    6. Extra Question: is it true to say that "Cardinality on staging table is always zeroMore and related cardinality is always "zeroOne ?

    if no, then:
    can you give me an example where in staging table i need to put related cardinality as Exactly one instead of zeroOne?

    can you give me an example where in staging table i need to put cardinality as ZeroOne one instead of zeroMore ?
  • Suggested answer
    Andre Arnaud de Calavon Profile Picture
    Andre Arnaud de Cal... 283,375 Super User on at
    BPErrorEDTNotMigrated
    Hi,
     
    I will try to help you but also need clarification on one question. Note that Microsoft changed table relations from EDT to tables. The current existing EDT relations are all legacy.
     
    1) Yes, adding the relation on the table instead of the EDT will solve the BP error. 
    2) On staging tables, it would be recommended to allow for all values. In that case, the details will load in the staging table and the copy to target process will then check for valid values. You can then correct the data in the staging table and it is easier for troubleshooting. If you don't allow incorrect values, loading the data in the staging table will be blocked.
    3) Can you explain this question with e.g. an example/screenshot?
    4) Yes. It does not make sense to have delete actions on the staging table as there is a separate cleanup job for data management history.
    5) The value No is recommended.

Helpful resources

Quick Links

Take the Community feedback survey!

Answer this brief 15-question survey about your Community experience…

Demystifying Copilot: Service Edition with Sundar Raghavan

Sundar answers more questions about Copilot for Service...

Dynamics 365 Business Central vs Finance and SCM

Take a look at the key differences between Business Central and…

Leaderboard

#1
Andre Arnaud de Calavon Profile Picture

Andre Arnaud de Cal... 283,375 Super User

#2
Martin Dráb Profile Picture

Martin Dráb 223,308 Super User

#3
nmaenpaa Profile Picture

nmaenpaa 101,140

Featured topics

Product updates

Dynamics 365 release plans