I will check it out, LJ - thanks! On Fri, Dec 8, 2017 at 9:55 AM, LJ LongWing <lj.longw...@gmail.com> wrote:
> 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 > > -- *Kelly Logan* | *Senior Consultant* 313-651-7169 | kelly.lo...@raptek.com *RAPID* Technologies www.raptek.com
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
