Skip to main content

When trying to run export operation from localhost admin center, error is thrown saying "Origin code 3389682780300157351 used on InstanceEntity(address) record 37150 not found!". Here address is one of the entity being used in my export operation.Attaching the error log file here and below is the export plan for the full load for policymaster export.Any help,highly appreciated.

 

Hi @debashishghosh ,

I haven’t worked with the MDM module for a long time, I’m not very familiar with export operations within that module, so I think we definitely need the assistance from some other MDM experts on here.

But to open up the discussion, here’s some starter questions:

  1. What version of Ataccama do you have?
  2. What happens if you make an export of just the address entity. Does that work?
  3. Maybe provide a screenshot of the details of the Policy_Master_Full export operation configuration?
  4. The error message is Origin code 3389682780300157351 used on InstanceEntity(address) record 37150 not found!
    • ​​​​​​​What is this 3389682780300157351 ? Where is it in the configuration? (The project is complaining about it so it must be expecting it somewhere?)
    • What does the address instance record 37150 look like? A screenshot of that would be helpful. Please feel free to redact sensitive information on a public forum!

(Summoning @AKislyakov or @Phil Holbrook ? 🙏 I’m not even sure if I’m asking the right questions.)


Hi @debashishghosh and @may_kwok 

The origin code is an engine-private identifier linked to the value set in the load plan for the field origin. It’s stored on every record as a code to save space and improve indexability rather than storing the origin string everywhere.

For that to be missing/not found something has gone properly wrong - it implies a database row has been manually edited or deleted, either in the instance table or in the origin lookup table

Specifically, that origin code should be present in the SQL table i__origin and be referenced in the instance table - probably c_address_i.

I'm not aware of any way the engine could have created this mismatch on its own: there must have been some sort of forced data insert or update - have you populated the database in any way other than a standard data load?


Hi all,this issue is resolved now,we had a pre existing data of different source system which was getting called here.When we cleaned those records from the table and ran it got fixed,Thanks for seeing through this .


Reply