Change custom data class attributes after they have been saved

Products

• Asset Management Solution
• CMDB Solution

Issue/Introduction

Can a custom data class' attributes be changed once they are committed by the user clicking on the "Save changes" button?

Environment

8.x

Resolution

Warnings:

(1) There are no out of the box abilities to change certain custom data class' attributes after they have been saved. The following instructions are intended as a solution and workaround for being able to change  a custom data class' attributes after being saved. While the workaround may work, it is not recommended to use this workaround, as issues may occur due to how the data was originally present in the table, which has now been changed. Because of this, Symantec Technical Support is unable to assist the user in implementing or troubleshooting this workaround.

(2) Before trying the workaround, it is recommended to test this thoroughly on a development server before trying it then on a production server. Also, the entire database should be backed up before trying it on a production server. If issues later occur, these can be restored.

Answer:
A custom data class' attributes, once committed by clicking on the "Save changes" button, mostly cannot be edited afterwards. This presents an issue if the user later needs to change these but then cannot. This is working as designed. To prevent issues and inconsistencies with the schema, CMDB intentionally prevents the user from changing some attribute values afterwards. The main name of a custom data class, however, can be changed by clicking on it and renaming it accordingly. (Note that this does not actually change the table name that it exists in, however, in SQL.) There is a solution and a workaround that can be used to be able to change custom data class attributes. Note: These instructions assume that the user is familiar with creating custom data classes and therefore specific steps to do so have been omitted.

Solution: Create a new custom data class as desired and then use it instead of the old one. This would then be assigned to its resource type. Then, remove the old custom data class from the resource type. However, this is only useful if the custom data class has no data or the user doesn't care that its data is lost.

Workaround: If the user needs to keep the data already in the custom data class, this would then need to be copied to a temporary table, then copied back to its original table after making the modifications. The remainder of these instructions show how to do this.
 

1. In SQL, locate the table name of the custom data class. This should be "Inv_<original_custom_data_class_name>".
2. In SQL, copy the custom data class' data to a new temporary table:
   
   USE Symantec_CMDB
SELECT *
INTO temptablename
FROM Inv_<original_custom_data_class_name>
    
3. In the Symantec Management Platform Console, delete the original custom data class. This also deletes its Inv_<original_custom_data_class_name> table, which is now backed up into temptablename. This also removes it from being associated to any resources on their create/edit page.
4. Re-create the custom data class as desired.
5. Add the re-created custom data class back to being part of a resource.
6. In SQL, delete the recreated custom data class table:
   
   DROP TABLE Inv_<recreated_custom_data_class_name>
    
7. Copy the temporary table's data back to the recreated custom data class, which recreates the table name and structure:
   
   SELECT *
INTO Inv_<recreated_custom_data_class_name>
FROM temptablename
   
   Note: This may present issues depending on what was changed and therefore the above SQL script may need to be changed, such as certain columns many need to be converted, etc., to accommodate the new table schema. For example, if a column used to be a string but is now a date, the SQL script would need to convert the types to be able to insert the changed types into the new table. This works better if only minor changes were made, such as increasing the size of a String attributes from 50 to 100 characters in maximum length.
    
8. Delete the temporary table:

DROP TABLE  temptablename
    
9. In the Symantec Management Platform Console, edit a resource that has data from the custom data class. This should appear as it did before, but enable the changes made to now take effect.

Additional Information

"How to create custom data classes" (KB 181379)