Wondering if someone can help me with a migration job issue.
I am trying to update a field within a Custom page. In below screenshot I need to update last column called Exported as YES (which can be a Custom enumeration or simple text). Please note, there can be multiple rows.
Jobs worked absolutely fine when there is only one row. But if more than one, it’s throwing below error:
Below are the Job details:
Question is what to update in the job to modify same Column on multiple rows? Above example I tried on Apps9 environment.
Thanks in advance
/D
Best answer by Technical Outlaws
Even though the OBJKEY is technically the key to a record in a Custom Logical Unit, it is a GUID value that is not easily accessible or identifiable to a user. The reason you are getting the error is because you have nothing mapped to the key, during the migration update process this will cause problems since it fails trying to find a unique record. Therefore to determine a unique record in a Custom Logical Unit you need to define an Alternate Key(s).
In your example above, for the Source Mapping you need to remove the K flag against the OBJKEY and set it to be I instead. Then you need to decide which column(s) that has a source column mapped should be the Alternate Key(s) instead and change its flag to be K. I believe what happens in the migration update process is that the logic will use the columns flagged as K to determine the OBJKEY in order to fetch the record for update.
Even though the OBJKEY is technically the key to a record in a Custom Logical Unit, it is a GUID value that is not easily accessible or identifiable to a user. The reason you are getting the error is because you have nothing mapped to the key, during the migration update process this will cause problems since it fails trying to find a unique record. Therefore to determine a unique record in a Custom Logical Unit you need to define an Alternate Key(s).
In your example above, for the Source Mapping you need to remove the K flag against the OBJKEY and set it to be I instead. Then you need to decide which column(s) that has a source column mapped should be the Alternate Key(s) instead and change its flag to be K. I believe what happens in the migration update process is that the logic will use the columns flagged as K to determine the OBJKEY in order to fetch the record for update.
In your setup I see both source and destination setup to the same custom logical unit - correct me if wrong. If that's the case from where you are going to migrate these data from?
Or is this for a different purpose like to have a default value only?
In your setup I see both source and destination setup to the same custom logical unit - correct me if wrong. If that's the case from where you are going to migrate these data from?
Or is this for a different purpose like to have a default value only?
Hi Rusiru
Thanks for your reply. I am not using two-stage migration job (i.e. not migrating data from any file) but trying to update Exported column as YES (by hard coding) on migration job itself.
Even though the OBJKEY is technically the key to a record in a Custom Logical Unit, it is a GUID value that is not easily accessible or identifiable to a user. The reason you are getting the error is because you have nothing mapped to the key, during the migration update process this will cause problems since it fails trying to find a unique record. Therefore to determine a unique record in a Custom Logical Unit you need to define an Alternate Key(s).
In your example above, for the Source Mapping you need to remove the K flag against the OBJKEY and set it to be I instead. Then you need to decide which column(s) that has a source column mapped should be the Alternate Key(s) instead and change its flag to be K. I believe what happens in the migration update process is that the logic will use the columns flagged as K to determine the OBJKEY in order to fetch the record for update.
Hi,
Thanks for your reply. I’ve changed the OBJKEY flag to I and CF$_EXPORTED_DB as K but unfortunately getting the same error message.
Take a step back and think about what you are doing. You are not seriously using a column that takes YES or NO to determine a unique record?! That will never work, hence why you are getting an error.
Think about what columns in your custom logical unit can you use to uniquely identify a record.
Take a step back and think about what you are doing. You are not seriously using a column that takes YES or NO to determine a unique record?! That will never work, hence why you are getting an error.
Think about what columns in your custom logical unit can you use to uniquely identify a record.
Hi @Technical Outlaws
Sorry I misunderstood- my bad.
Identified the unique column and all working fine now :)
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.