A column created on a base table (such as cmdb) is not available to a child table (such as cmdb_ci_win_server) after transferring that column to another instance using an update set. However, the column is still available to the child table on the source instance.
Steps to Reproduce
- Create an update set on a Jakarta instance and make it your current set.
- Create a new column on a base table such as cmdb called u_owner_group as a reference to the group table.
- Add this field to the cmdb_ci_win_server form layout.
- Complete update set.
- Preview and commit the update set on a target Jakarta instance.
- Navigate to a cmdb_ci_win_server form.
Note that the new Owner Group field is not on the form and there is no sys_dictionary or sys_storage_alias record. Note that there is a sys_dictionary for u_owner_group on the base table cmdb. The u_owner_group field should be available to the cmdb_ci_win_server form
- If you are on Jakarta and have not yet committed update sets, that are adding custom columns to base tables that have child tables, then you can use the following workaround BEFORE committing update sets, to prevent this issue:
- Navigate to sys_properties.list
- Create the property "glide.db.bootstrapbatcher.support_partition_tables" with a value of false.
NOTE: This will turn off schema alter 'batching' for partition tables. Schema alters are still fully functional, just not in batches.
- If you are on Jakarta release and have already committed update sets, that are adding custom columns to base tables that have child tables, and you believe you believe you are affected by this issue, please contact ServiceNow Customer Support to ask about remediation options.
Related Problem: PRB1096046