Did it ever happen to you that you created a table in the wrong scope or the technical table name itself does not follow the defined naming conventions? Two days and 60 custom fields later you realized this but the due date is approaching fast. Just happened to one of the developers in one of our many projects. Now what?
Sit back, take some coffee, or tea, and think about it for a while. What happened? (don't think too much about the "why" for now)
How can this be solved in an easy way, without panicking. Since it is all XML, we might be able, with some easy steps, to get this fixed fast - Yes you might have to work two extra hours, but not days.
And you will not go crazy. Instead, you will have learned something.
1) In your current scope, identify all updates of type "Dictionary" regarding the "wrong" table. Put them in a separate update set.
2) Export that update set to disk, it will be one big XML file.
3) Both screenshots below show what needs to be changed, just put the new values there.
Make sure not to forget the XML structure inside the "payload" attribute.
Note: If you stay in the same scope, you do not need to change the application/scope attributes.
4) Now you have to delete the not needed and just exported columns from the platform.
5) Before we can import the changed update set into the correct scope we need to create the new table (make sure the table name matches to what you decided here, in my case "my_new_table").
6) Import the XML, preview and commit. All columns should exist on your new table now.
Last but not least, If you already created other artefacts, like column labels or choice list values, you should be able to re-use them in the very same way.
Please try this on your PDI first. And apply at your own risk of course!
Let me know if this was helpful for you by clicking the button below. Thanks!
2 Comments
