Scoped Application Issue: Global "Delete" UI Action Error

Logan Poynter
Mega Sage
Mega Sage

I'm working on a scoped application and have run into an error message that I cannot find any ServiceNow specific documentation on, or let alone a cause. I have the Global "Delete" UI Action shown on my record - no override in place - and when clicked and confirmed, the record deletes but I am given the error message "(conn=21558) ALGORITHM=NOCOPY is not supported. Reason: Cannot change column type. Try ALGORITHM=COPY"

LoganPoynter_0-1671380244684.png

 

The only documentation I can find relates to InnoDB (MariaDB)? When the delete action is performed, there is no logs recorded by the system. Anyone have some insight into this? 

7 REPLIES 7

Jesse10
Tera Contributor

I'm with this problem. Can tell me the cause?

The cause seems to be that the columns in the shadow table that were registered when the record was deleted are different from the columns in the actual table.
Shadow tables are created in the sh$<tableName> format and are normally invisible, but are used during rollbacks.
Didn't you change the column definition before the error occurred?

There are two solutions

1. Return column definition
There will be no difference and no errors will occur.

2. Recreate the column


The problem can be solved by creating a separate column with the same content and deleting the old column.

If you don't know the target column, use a background script.
If you catch an exception with try and catch when deleting a record,
ALTER TABLE tableName MODIFY `u_column_name` VARCHAR(10), algorithm=nocopy, lock=none
You should find a column like this.

 

What do you think?
Although time has passed, I'm sure there are still some engineers who are worried.
I hope this reply is helpful!

If you found this helpful, please press the thumbs up icon to mark it as correct! !

Ian Catley
Tera Contributor

I had the same problem when trying to delete a task and then an attachment, which was on the task. It seems to have been due, in my case, to the delete of the task causing a cascaded delete of the attachment, which then clashed with my explicit delete of the attachment. Changing the order to first delete the attachment and then the task got rid of it. Maybe it is something similar happening in your case?