Why can I not delete my own custom table in a scoped application?
When trying to delete a custom table from a scoped application the "Delete Table" button is not available. This is because of a known problem: PRB762839 which has an intended fix version of Orlando
We have restrictions in our system so you do not delete specific tables in your instance and currently you are blocked from deleting custom tables in scope applications. Currently the workaround is to contact Customer Support and they will assist you in removing the customer table from the scoped application.
More Information here: KB0623901
Why can I not add 'update_synch' to my custom table?
The reason for this is stated in our documentation here
Warning: Do not add the
update_synch attribute to a dictionary record. When improperly used, this attribute can cause major performance issues or cause the instance to become unavailable. Adding this attribute is not supported.
We do however have an OOB UI Action on sys_db_object "Track in Update Sets" which can be used to get a custom table to be tracked in update-sets by getting this re-parented to sys_metadata. But this should be used with caution and used in legitimate limited circumstances.
To use this UI action there is a list of criteria that it needs to pass to use this UI action so please review all the information on this KB before proceeding: KB0726953
How many columns can be stored within a physical table
The number of columns within a table is defined by the database used and not by the ServiceNow platform
MySQL limit, not controlled by ServiceNow: There is a hard limit of 4096 columns per table, but the effective maximum may be less for a given table. The exact limit depends on several interacting factors.
Every table (regardless of storage engine) has a maximum row size of 65,535 bytes. Storage engines may place additional constraints on this limit, reducing the effective maximum row size.
The maximum row size constrains the number (and possibly size) of columns because the total length of all columns cannot exceed this size.
Oracle supports up to 1000 columns per physical table. Please refer to Oracle documentation regarding this:
Design considerations when creating table/adding columns
It is recommended at the design stage to look at the normalization of your data to reduce white spaces and ensure your data is organized efficiently
There are numerous external articles regarding database normalization as this is not a ServiceNow process i.e.
Please find a simplistic example of something considered bad design:
In this example, there is a table with 9 fields named u_finding followed by a prefix of 1-9
If a record was inserted which only populated 2 of the 9 fields, it would leave 7 fields unpopulated. These 7 fields are what is considered white spaces
To resolve this issue you could create a separate table to store all the finding which references the u_research table i.e.
Every finding would be created in the table u_finding and link to the originating table u_reserach. This way a u_research record could have multiple findings. This approach would eliminate white space
I am using a calculated field. Why is the order incorrect when applying a sort on this field?
With calculated fields, the data is returned in real-time when accessing the data via a list view. When sorting on the field the sort will be applied based on the values saved in the database
The values stored in the database will be from when the record was last saved which can differ from real-time data
If you really need to sort on this field you should consider removing the calculated option and creating business rules to ensure the field is updated when related records are updated.
I received the error "Max column count per table reached". What does this mean?
The system can only have a maximum of 1000 columns per table. If you receive this error it is because you have reached this limit.
Please note that although it is defined that 1000 columns is a specified limit, this does not mean you can physically have 1000 columns within a table. See section: "How many columns can be stored within a physical table"