I have two scrips both numbered 0 under http://hostname/Admin/Global/Scrips.html and when I try removing them from that page nothing happens… I then try to remove it from the database like this:
delete from ObjectScrips where Scrip = 0;
Query OK, 1 row affected (0.01 sec)
but when I upgrade the database later, the two offending scrips are added back. do I need to delete them from more tables than just ObjectScrips?
Can you give us a screenshot of this page. Database schema do not allow for two scrips having the same Id (primary key)?
BTW, if you wan’t to remove a scrip manually, you have to remove it from ObjectScrips, then from Scrips tables.
Maybe you have a problem with this table sequence, seems you’re using MySQL and I’m not a specialist on this DB.
I was going to create a new ticket but this one is ideal and recent - I have v4.2.13 instance just upgraded from v4.0.x, I’ve logged in as the root user and I’m on the Admin -> Scrips -> Select page, looking for a way to delete a scrip. The screenshot in this thread shows checkboxes and then the suggestion of a way to delete, but I don’t have this:
Is this broken? I can only disable currently.
Thanks for any help.
Hi lurker,
This isn’t broken, it’s by design. In general RT doesn’t “delete” things, it disables things. This makes it easier to undo the deletion, among other things. In the next set of releases, disabled scrips will be hidden by default so there’s less of a need to delete them.
If you still want to delete them, you can use shredder.
@shawn can you please also address my question? I do not really want to delete those 2 scrips if they can be disabled, however, when upgrading it fails because they both have id = 0.
Sorry for the delay in replying, I wasn’t emailed about any responses here…
Leaving them alone would be ‘broken design’, since they refer to RTIR, which has been removed from the current installation of RT. I’ll look into shredder for deleting scrips, thanks.
Lurker writes:
Leaving them alone would be ‘broken design’, since they refer to
RTIR, which has been removed from the current installation of RT.
They should be edited with the script instantly aborted or made into a comment instead. Add a note explaining why. Then deactivate. This way you preserve history, while ensuring the scrips must be edited to make them able to do anything.
/jeff
@lurker and @Jeff_Pilant can any of you please address my initial question? I do not understand why I keep getting unrelated answers to my question.
shawn mentioned you can use the shredder to delete the scrips from the DB if you really want to. However, as someone who had to take over a system where one of the previous folks running the RT instance had done just that, I would recommend against it. It led to a good deal of unnecessary work on my part when I had to support it later on.
@Greg_Vernon thanks, but if I don’t do anything about those scrips, the database upgrade keeps failing. is there any other way than the shredder then? also, where can I read more about how to use it?
Ah, now I see what you mean. Are you using MySQL?
Have you run rt-validator on the instance? It might give you some better clues.
And looking closer at this, it looks like your sequence for the DB has perhaps run out of values? Or it did at some point. On my system ‘On Queue’ change isn’t there, but I’m on an older version. The other scrip is on my system but with a non-zero id. I suspect you shouldn’t have ANY ids for a scrip with a zero value.
I suspect that someplace the sql wasn’t quite right and only the description got inserted without any sort of id reference. MySQL being MySQL, it happily put a ‘0’ there as a value even with a NOT NULL constraint.
rt-validator might help out with some of this by letting you know what things are broken. Run it ONLY with the -cv flags, as you don’t want to change any of your data. Better yet, if you can do it on a test server, do it there.
It’s just simply:
rt-validator -c -v
You can just run rt-validator -c to do a simple check, but it’s nice to know what’s going on the first few times of running it. Also, running it with no options will give you help. It’s not hard to invoke it. But once you start changing data, it can be dangerous. When you do start to want to change data, run it on a test instance where you’ve recovered your DB until you know exactly what it’s going to do.
rt-validator can be a bit like pulling a loose thread if you’re not careful. I once started completely unzipping my DB with it. Fortunately, that was on a test server. 
If things look pretty messed up, it’s worth getting the folks from BPS involved.