Hi Kelly –
I am sure LJ’s tool will work, just wanted to point out what we did in the past. We have used rrrChive (a free utility) to remove a lot of tickets (we are not an ITSM shop, most everything custom). What we did, was use the MOVE functionality, give it an ARX file to dump it to, and no receiveing system for it to go to. The end result was arx files, along with attachments, etc. that were dumped to a server. Our use-case was to archive the data on the server for a year, then delete, however if you don’t care about the data, you can simply delete the arx and subfolders.
From: ARSList [mailto:arslist-bounces@
arslist.org] On Behalf Of Kelly Logan
Sent: Friday, December 08, 2017 12:05
Subject: Re: Best way to delete records
I will check it out, LJ - thanks!
On Fri, Dec 8, 2017 at 9:55 AM, LJ LongWing <firstname.lastname@example.org> wrote:
I have a tool on my website (http://remedylegacy.com/
tools/delete-requests/) that might do what you want. It's designed to allow you to issue SQL Queries to identify records that need to be removed, and then removes them via the api. You could in theory issue a query to say the task form and say give me a list of all tasks that are associated with incidents I want to remove...and it'll remove those tasks....you of course would want to remove all of the children before the parents...or, alternatively you could use this tool to delete all of the parents first, and then do an sql query on the children records and delete any orphans that were left behind...
On Fri, Dec 8, 2017 at 8:40 AM, Kelly Logan <email@example.com> wrote:
We are working on a mass delete system as well, to remove a section of data belonging to one group. In addition to the concerns of the mass delete of a number of records, I am also looking for an efficient way to remove their child/transactional records as well. While the parent records can be found with a simple query on the company name, this field is not on most of the related records. Instead I am left with a list of parent record ids. I am looking at ways to feed these in process-able chunks to other delete commands for the related records.
I am looking for the fastest and least error-prone method on ITSM 8.1 as this will likely need to run during a maintenance window.
Any advice on what deletion processes are the most efficient and/or handy tricks to clear out related entries using other methods? I am currently considering workflow, Pentaho Spoon and workflow generated SQL.
Also, any references for ITSM 8.1 data models (an ERD for each of the applications would be really handy) would be greatly appreciated.
On Fri, Dec 8, 2017 at 8:34 AM, Pattabiraman, Vishal <firstname.lastname@example.org> wrote:
I had worked on a requirement were we had to purge records. What we did was, take SQL logs and check all the dependent tables that gets affected.
Create a SQL job that mimics the same functionality and include it in Scheduled job. The best part of this solution was, it was powerful and silent. No ARS service downtime.
Hope this helps.
We have a form in Remedy that we upload user access information into on a bi-weekly basis. (There is about 300,000 rows) Prior to uploading the data to the form, we delete all of the current records and then upload the new data. We have been using the Application-Query-Delete-Entry in an escalation Run process to delete the records. This process worked fine in version 8.1 but has stopped working in version 9.1.3. I did find an issue related to the Application-Query-Delete-Entry causing a memory leak which causes the deletion to fail. It was supposed to have been fixed in patch 1 but we are still seeing the issue after installing the patch. Which brings me to my question, is there a better way to delete all the records other than using the Application-Query-Delete-
Entry? As a work around for now we set up a job on the SQL server to truncate the data but I am not sure that is a good work around. I appreciate any suggestions.
The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be protected under state or federal law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please forward the communication to email@example.com immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
ARSList mailing list