No sys_class_name on extended table when installed or loaded from an update set

jbenedict
Kilo Contributor

I am wondering if anybody else has seen any issues with packaging a scoped application where you have a base table and extended tables from that base table.   I had no issues with setting up the application in my development environment but once I made the application available for install to other SN instances or I loaded my application from an update set the base table is missing the sys_class_name field.   This introduced issues for me for I was also loading data records from this table and without the sys_class_name field the records were not getting setup properly.   After install or update set load all it took was a simple update to the base table definition in order for the sys_class_name to be added but this caused further issues with my loaded records.

Here is what my base table looked like after install of my application in the target ServiceNow instance (same behavior if I load it via an update set).

NoSysClass.PNG

When loading through an update set I would get added errors due to the lack sys_class_name field, these look like:

UpdateSet.PNG

For now, my workaround is to omit my data records from my application install and then via instruction make an update to the base table definition and then lastly load the data records after the table has been updated to contain a sys_class_name field.

Thanks.

5 REPLIES 5

David_Gatley
ServiceNow Employee
ServiceNow Employee

joe.davis chris.tucker Christopher.Maloy do you guys have any idea why jbenedict is seeing this?


+ Anson



David - can you get Anson details on the update set issue? Sounds like the table is not built correctly fwiw


David_Gatley
ServiceNow Employee
ServiceNow Employee

Hi Jeff,


Which instance are you seeing this on? (Feel free to email me if you wish to take this offline).


David,



I am seeing this issue within our ven01091 instance with our Employee Self Service Portal and Catalog application.   I did try to recreate the issue with another Test application (in that same instance) and that did not have the same issue.   For the application that we are seeing the issue we are also using team development to move updates from other instances to our ven01091 instance so it might have something to do with these tables originally being created in another instance and moved via team development.