1 of 1 people found this helpful
I would recommend opening a ticket with support on this, they may be able to assist you with the least destructive way of sorting out this rogue table.
Whilst your suggestion is logical, it is possible that they key fields within the table are referenced elsewhere, and replacing the table with the old, pre-upgrade version, may break other things than the obvious of loosing new templates.
Thanks for the thoughts silverbacksays
We are absolutely working with support but we are not getting very far yet. Their suggestion is to try a repair, which failed, then a reload the table from before the issue started, which was before the upgrade. I've emailed back with my concerns but wanted to try thwack to see if anyone else has feedback.
Thanks for expanding on that Steven.
Keep this thread updated, if you don't mind, as I'll be interested to see the outcome. Looks like you're in a bit of a bind there, so I hope you can get it resolved without having to resort to a repair.
Still trying to work with support on this issue. The table corruption happened because of our last Orion upgrade. The upgrade changed the Description and ViewXml datatype fields changed from ntext to nvarchar in the APM_ApplicationTemplate table.
Despite the integrity error the suite is working just fine. We can add, remove, and assign templates without issue.
We have fixed the corruption with a test environment, but it removes all of the records in the APM_ApplicationTemplate table, including the out-of-the box and custom templates. This loss means all associations between actively assigned application monitors and their respective templates are lost.
More concerning is that Support has also confirmed that all SAM historical data and assigned application monitors may be removed and will need to be reassigned. This is a non-starter for us as we can not lose this data.
I am still pushing for a more custom support solution. The ideal solution would be to work with development to make sure our data is not lost after doing the repair, or working through those 173 application template records and find out what we can do to make the Description and ViewXml datatype fields that have changed to be valid as nvarchar datatypes.