Why migrating an update set with table changes (including creating an extended table) is not commiting as expected? - Support and Troubleshooting

Why migrating an update set with table changes (including creating an extended table) is not commiting as expected? Description  Committing the retrieved remote update set on Target instance was not creating table with extension.

For example, let's say, on a source instance, administrator has created a custom table which extends task table, this table creation is captured in a update set.

When administrator commits the tables changes on a target instance, system suppose to create the same custom table with same extension. However, table was not created with extension.

Release or Environment Any supported release.

Cause On the target instance, before applying the update set, an user has created the same table without extension and hence extension changes from the update set is not committed.

Local host node logs reveals following entry:

2018-07-30 04:43:26 (051) worker.1 worker.1 WARNING *** WARNING *** Prevented attempt to reparent , from null, to Resolution If the target instance is not PROD instance, clone the target instance from PROD and then apply the update set. This is the preferred way so that update set would be tested thoroughly before applying it on PROD instance.

Else if the table doesn't have data and clone is not an option, drop the table and recreate it with extension ( If table has any data, those data needs to be backed up before dropping and then moved to the new table).

Additional Information Update set

Commit an update set