Reappearing table default attributes, usually after an upgrade and why this occursDescriptionAdministrators may notice that attributes that they have previously and intentionally removed from a Dictionary record suddenly seem to reappear immediately after an upgrade of the instance.CauseThis is expected behavior. During an upgrade, the default attributes that are associated with Dictionary records will automatically be replaced if they are not found on that record during an upgrade of the object. This may be rather unexpected and could result in behavior for that field or table behaving in a way that it did not prior to the upgrade.ResolutionThis is the designed behavior of the system and will always occur when that object is updated during an upgrade. However, with the proper configuration of the dictionary attribute, this behavior can be prevented from actually causing any change in the field or table collection record. During the upgrade of an object, the attributes that are associated with that Dictionary record are compared. If any of the original default attributes are missing they are re-added to that dictionary record. Any attribute that was removed will suddenly appear again associated to that dictionary record. However, the system simply checks for the appearance of the attribute during an upgrade. As long as the property is actually found associated with the dictionary record, the current property and its setting will be retained for that record during the upgrade. A common shorthand for true/false valued attributes is to simply add the attribute name to the dictionary record, which coincides with a true setting for that attribute. If that attribute is NOT found associated with that dictionary record, this attribute is then assumed to have a value of false for that dictionary record. For example, the following property setting might be added to the attributes field: show_all_tables This would set the attribute show_all_tables to a value of true (which, for this particular attribute, would allow users to select system tables from a table selector field type). Similarly, to have this attribute set to false, the attribute could simply be removed from the sys_dictionary record for that field or collection. Therefore, for that sys_dictionary record, it would be implicitly assumed the value for that attribute is false since it is not actually found associated with the sys_dictionary record. After an upgrade, it might suddenly be found that the show_all_tables attribute was re-added to this sys_dictionary record (if that attribute was already originally associated to that field by default at the original provisioning of the instance). In a similar manner, completely removing an out-of-box non true/false value attribute from a sys_dictionary record will cause that attribute to be assigned a default value for that attribute. However, during an upgrade, the out-of-box attributes associated to that field will be re-added to the sys_dictionary record if that record is updated during an upgrade. Therefore, the recommended method to prevent these unexpected reappearances and possible resetting of the set value for that attribute is to use a slightly different format when specifying or changing that attribute's value. Thus, to explicitly set this value to true, the following syntax could be used: show_all_tables=true And, to set that same property explicitly to false the following syntax might be used: show_all_tables=false Thus, since the attribute is found to already be associated to the attribute (regardless of the actual value set for the attribute), the upgrade engine would not automatically re-add the missing attribute which could have the result of changing the attribute value and subsequently changing the behavior for that field or collection record.Additional InformationThe following Knowledge Base article shows the various attributes that can be associated to some dictionary records:Dictionary attributes Warning: Don't use this trick for no_audit. It won't work due to PRB652404. In this case, use:KB0869832 [Auditing] New audit modes introduced in [Istanbul] and how to enable auditing for a table that is set to [no_audit] out-of-box (OOB) using the new white-list audit mode, so that it is not overwritten after an upgrade and it continues to audit the field.