Move a table that is extended from task to sys_metadata

[bradwestvig]

We have create some tables that are extended from task.  This was done incorrectly and I want to extend it from sys_metadata (Application File) to be included in our application.  The data is a part of our core application code and needs to be migrated when the application is installed, or when we update it.

Any thoughts on a way to migrate these changes?

[Allen Andreas]

Hi,

This may not be possible or could negatively impact the table altogether, but check this thread here and see if this works for you. I'd recommend testing similar scenario in your PDI first.

https://community.servicenow.com/community?id=community_question&sys_id=77e912f0db202744200f0b55ca96...

Now this talks about they didn't set the extended table field, but now want to...but I'm sure it's along the same lines as what you're doing which is basically making that field "writable". 

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Allen Andreas]

Hi,

Just wanted to check-in and see if your issue has been resolved.

If you don't mind, please mark my reply as Helpful/Correct, if applicable. Thanks!

[Dipu Joy]

Hello Brad,

Extend a table from sys_metadata is a big decision to make as it can affect your instance performance all together.

When you extend from sys_metadata, all INSERT/UPDATE/DELETE are captured in sys_update_xml.

If sys_update_xml is huge, it can create issues with Upgrade/Plugin installations as it needs to load to the instance cache for creating the hash on what to skip/modify ( based on the field Replace on Upgrade).

So adding a custom table extended from sys_metadata should be analysed on a bigger scale and should be used legitimately.

Please find more information from the KB

https://hi.service-now.com/kb_view.do?sysparm_article=KB0726953

To answer your question on changing the extension on an existing table. There are lot of reparenting scripts available in the forums and it might/might not work and ServiceNow do not recommend/support this.

One of the safest option ( not easiest) will be to Import the existing data from the table as CSV/Excel and then remove the custom table and recreate it correctly and then use Import -set to load the data again.

Thanks,
Dipu Joy

[bradwestvig · Accepted solution]

To update this post I opened up a HI ticket with Support and they helped me reparent the tables.  They have an API that does it, but its not available for end user usage.  The tables have now been reparenting and are working as expected.