Consider the "incident" table
Under sys_db_object table, ServiceNow lists 161 columns
You can see that it shows columns from parent as well as incident table
But if do the following:
var body = {};
var recObj = new GlideRecord("incident");
if (recObj.get("<some sys_id goes here>") {
var data = recObj.getFields();
for (var i = 0; i < data.size(); i++) {
var field = data.get(i);
var name = field.getName();
var value = field.getValue();
body[name] = value;
}
body.sys_id = recObj.getUniqueValue();
}
gs.print(Object.keys(body).length);If gives me a count of 182 and I see certain columns with names that I don't remember creating.
Why is there such a huge difference? I'm sensing getFields() is also pulling columns that might have been deleted from the table but is there a way to confirm this?
Any suggestions?
The incident table extends from the task table, so getFields() returns fields from both incident and its parent tables, not just those directly defined on incident. In contrast, sys_dictionary (used by the Tables & Columns UI) shows only fields explicitly defined on that table
@kaushal_snow I understand the getFields() queries entries from hierarchy but if I use "table is ONE OF incident,task" on sys_dictionary, the numbers still don't match. Refer the screenshot below
That is what I'm trying to understand. Why is there a difference of around 20+ columns between sys_dictionary and getFields()
Via Script - 106 (it excluded the 2 collection type fields as that's expected as those are not actual fields on table), 1 each for task and incident
Via dictionary - 108
@Ankur Bawiskar See - that's even more surprising. I'm doing the same thing as you but getting a difference of 20+ columns. Where are those extra columns coming from in the getFields() function?
to confirm if any field is deleted, check "Deleted Records" left nav module and check
Isn't sys_audit_delete table for data audit and not schema audits?
