Kelly, 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 <kelly.lo...@raptek.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 < > vishal.pattabira...@cgi.com> wrote: > >> Hi, >> >> >> >> 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. >> >> >> >> Thanks! >> >> Vishal >> >> >> >> *From:* ARSList [mailto:arslist-boun...@arslist.org] *On Behalf Of *Arner, >> Todd >> *Sent:* Friday, December 08, 2017 7:50 PM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Best way to delete records >> >> >> >> 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. >> >> >> >> Thanks, >> >> Todd Arner >> >> Great Lakes >> ------------------------------ >> >> 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 no...@glhec.org 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 >> ARSList@arslist.org >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > > > -- > *Kelly Logan* | *Senior Consultant* > 313-651-7169 <(313)%20651-7169> | kelly.lo...@raptek.com > > *RAPID* Technologies > www.raptek.com > > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
