I downgraded from DM 10.2 CU02 to 10.1 CU23 (MySQL based system) and received the following notice. Will this possibly cause issues? Should I manual remove the extrastatusid column from the table?
”
In general: 0 error(s) and 0 notice(s)
————————-
DataMiner Agent ‘WIN-HCKI8MS6H8K’: 0 error(s) and 1 notice(s)
Notices
– Table alarm has an extra column extrastatusid which is missing from the definition
”
Thanks
Hi Jeff,
The extrastatusid column is a column that is added in 10.2 but not used in 10.1. It is not necessary to remove it from the table and should not cause any issues.
Hi Jeff, if it can be of any help:
The extrastatusid column was introduced as part of storing masking information for alarms even when the alarm is cleared (See https://community.dataminer.services/documentation/dataminer-v10-2-0-release-notes/#:~:text=issuesorexceptions.-,DMSRN14,-Maskedalarmswill ).
As far as I see, the default read-out of the field is “not masked” and upgrading with the column present should have limited impact. Worst case, a masked alarm could show up as unmasked (but I don’t believe so as the main status should remain masked)
Thank you for the feedback.
Thanks for the info. Any issue if/when you later upgrade back to 10.2? This type of problem happened with 9.5->9.6 elementinfo_dve table. The dve_enabled column was added in 9.6 and if you downgraded back to 9.5 and then later upgraded back to 9.6 the dve_enabled field did not get initialized properly causing all DVEs to be disabled. This required us to remove the column after downgrading back to 9.5 so when it was later upgraded back to 9.6 this column got initialized properly. Concerned that a similar problem could happen with this new extrastatusid field.
Thanks