Record not found....

[wac]

Hello!

I have encountered a very strange issue. I created a table which inherited from cmdb_ci a while ago. After some redesigns we come to the conclusion that we don't need that table anymore. So I followed the steps described here: http://wiki.servicenow.com/index.php?title=Deleting_a_Table

However, something seemed to went wrong, since the Locations (cmn_location) didn't load properly anymore. After looking around, I found that we still have CIs based on the deleted class. If I try to open that record I get: "Record not found" however the entry seem to have a sys_id (right-click on the record -> copy sys_id).

My conclusion is that something must have gone wrong and that the cascade rules for deleting reference fields didn't work properly. Is there any way I can delete those records?

Thanks,
Chris

[#2]

Use the following at your own risk, and by all means use them in a "sand box" environment first.

With the gs.sql command you can delete the orphan records.

In "Scripts — Background" you can run a command like
gs.sql("delete from task where sys_id="c0bea5bc4dbea000c38e14964013369d'")

[wac]

Hello!

Thanks for the quick response. So in my case I would call that script on the cmdb_ci (as the most parent/top) table? Can you explain what the technical reason for this behavior is? One would think that deleting a record actually deletes that record.... so displaying a record means that there is one.

Do you know where SNC gathers its information to display records. (It is there but somehow isn't.)

Just sort of confusing to me.

Cheers,
Chris

[#4]

That is most likely correct.

You can always test it first by using the same gs.sql to perform a select first on the sys_id for that table.
If you receive 1 record then you have the correct table.

Example:
gs.sql("select count(*) from task where sys_id="c0bea5bc4dbea000c38e14964013369d'")

[CapaJC]

Laurens, we will henceforth be sending all Incidents your way from anyone who manages to hose their instance using gs.sql 🙂

But seriously, Chris, use with extreme caution. gs.sql doesn't have any protection against doing something wrong. It'll do what you tell it, no question, "are you sure?".