Committing an update set changes some fields to their default values

[Kyle Brown]

Hi all,

We're currently experience a strange behaviour where if we commit an update set that interacts with the Change (change_request) table, some custom true\false fields (but not all) are having their values set to their default (false) on all records on the table.

For example, we have a field called CI Not In List, to be used if a user can't populate the Primary CI field as the CI they are looking for isn't registered to the CMDB. We also have a field called Security Approval Required, to be used to help drive workflow approvals based on what the Change Request is for.

When we Commit an update set that updates something on the Change table the following happens:

• The update set progress checker shows the following message "Running Child progress: Applying scheme change: task - Updating default values: %fieldname%
• Every record in the Change table that is set to CI Not In List = true is set back to false, with no updates in the audit log or record histories
• Ever record that has Security Approval Required = true is left alone, the data in this field is retained

I'm not sure when the behaviour first started as the Change table has been fairly static for about 5 or 6 months up until a couple of months ago. We're on Kingston Patch 9 and running on-premise.

Obviously this has major implications for the quality of our data in the toolset if we can't get to the bottom of it. Does anybody have any ideas?

Regards,

Kyle

[asifnoor]

Hello Kyle,

Did you check the changes that an update set contains? May be something is triggering from that. 

Is there any changes in the update set to the parent table task?

[Kyle Brown · Accepted solution]

Hi,

Thanks for the reply. Yes I checked the update sets, I even created a new one with only a field label change to a field on the Change table in it and it still did the same thing.

I think I might have worked out what is going wrong though. 3 fields are being affected. 2 of them, when viewing their dictionary entries don't display their labels correctly and seem to be corrupted somehow. Fortunately we don't use these fields.

Deleting the 2 fields from the table has stopped the 1 we actually use from reverting to it's default value.

I have no idea why this would happen, but I expect it's something to do with the way the database groups fields of a similar type. The behaviour of the update set committal was almost like it thought those fields were brand new every time, resulting in a schema update.

Very strange, but there we are.