When altering an existing column by changing the field type or the field length, data loss can occur if the field has duplicate storage aliases. On an affected version, the logic that safeguards against data loss fails to account for data in fields that are aliases of the field being modified. The following workflow illustrates the issue:
- The user accesses a field on a table that is configured as an extension of another table (Table per Hierarchy).
- The user then alters the field by changing either its Type or its Length.
- The execution logic tests for data loss in that table only (not the entire hierarchy for the field).
Because the test does not detect any data in other tables that are also extensions of that same base table, the workflow continues to execute, causing data loss for that field in the other tables.
Steps to Reproduce
ServiceNow does not recommend any attempt on the part of the customer to reproduce the issue. If you have made a change to a field definition and have experienced data loss, please escalate to the ServiceNow support team for their assistance with an investigation.
ServiceNow is executing a maintenance change that will add a logical test to the workflow to cleanly abort when the risk of data loss is present. You may see one of the errors below when attempting to execute the workflow after the guardrail is in place:
- Element is using storage alias. Cannot modify this element's type because it shares a storage alias. _alias_
- Element is using storage alias. Cannot shrink this element's length because it shares a storage alias. _alias_
- Update aborted because duplicate storage aliases defined for element [_name_._element_]
A workaround is not available at this time, but the issue is fixed in the available product releases listed in the Fixed In section below.
Related Problem: PRB674257