Hi, "no way" to disable workflow might not be completely true.
There is a more intrusive way that is built into RRR|Chive, where you can say disabledeletefltr=YES. This will temporarily disable any Delete-only-filter, or remove the Delete-execution on filters with multiple execute-on conditions. But I think I agree with Ben that there SHOULD be flags to disable workflow completely, just as the built in AR_MERGE_NO_WORKFLOW_FIRED option to the ARMergeEntry API-call. This would not be something you would normally, but something you use when you synchronize data. Best Regards - Misi, RRR AB, http://www.rrr.se (http://www.rrr.se) (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13) * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs Find these products, and many free tools and utilities, at http://rrr.se (http://rrr.se) December 10, 2017 5:37 PM, "Ben Chernys" wrote: Meta-Delete has always been part of Meta-Update. It does deletes by query as a command. You can use Meta-Query first to save the data or confirm it. Remember that there is no way to inhibit workflow in deleting records. ITSM, more so in the current releases, tends to have workflow that ensures no “orphans” are left behind. This is basically a Push Fields giving a delete signal and would be propagated down the levels of children. So deleting a root request like an Incident has a heavy workflow penalty. Hence, no matter what you use, always delete from the bottom up. Further complications arise because some tables require an update before a delete. An examples is CTM:People requiring a status change first. In these cases, a 5 line Meta-Update script is needed to do the assignment and then issue the Application-Delete-Entry after. When you want to delete all records of a table, there is nothing wrong with truncate. Just make sure you truncate all tables of the DB that represent the single ARS table. Cheers, Ben Chernys Senior Software Architect Canada / Deutschland Mobile: +49 171 380 2329 GMT - 7 + [ DST ] Mobile +1 403 554 0887 Email: Ben.Chernys_AT_softwaretoolhouse.com (mailto:Ben.Chernys_AT_softwaretoolhouse.com) Web: www.softwaretoolhouse.com (http://www.softwaretoolhouse.com/) We are a BMC Technology Alliance Partner Check out Software Tool House's free Diary Editor and our Freebies Section for ITSM Forms and Fields spreadsheet. Meta-Update, our premium ARS Data tool, lets you automate your imports, migrations, in no time at all, without programming, without staging forms, without merge workflow. Meta-Archive does ITSM Archiving your way: with your forms and your multi-tenant rules, treating each root request as a complete tree and checking associatuions. Archive output to different servers, HTML pages with links to attachments. Data and links to pages can be set in a Remedy or ServiceNow form. Pre ITSM 9.1.02? Clarify? Roll your own? No problem! You can keep your valuable data! http://www.softwaretoolhouse.com/ (http://www.softwaretoolhouse.com/) From: ARSList [mailto:arslist-boun...@arslist.org (mailto:mailto:arslist-boun...@arslist.org)] On Behalf Of Jason Miller Sent: December-08-17 1:00 PM To: ARSList Subject: Re: Best way to delete records Using RRR|Chive was my favorite way before LJ built his tool (I was his guinea pig, I mean tester). Both are great ways to delete records and can do it way faster than Escalations and a bit more safely than directly in SQL. This conversation in the BMC Communities we talked about some of the specifics of using RRR|Chive to dump records: https://communities.bmc.com/message/615453 (https://communities.bmc.com/message/615453). In my case I didn't want any archive copy so the least amount of data written to disk (especially attachments) the faster the whole process could go. Jason On Fri, Dec 8, 2017 at 12:17 PM, Mike Galat wrote: 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. Thanks, Mike From: ARSList [mailto:arslist-boun...@arslist.org (mailto:arslist-boun...@arslist.org)] On Behalf Of Kelly Logan Sent: Friday, December 08, 2017 12:05 To: ARSList 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 wrote: Kelly, I have a tool on my website (http://remedylegacy.com/tools/delete-requests/ (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 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 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 (mailto:arslist-boun...@arslist.org)] On Behalf Of Arner, Todd Sent: Friday, December 08, 2017 7:50 PM To: arslist@ARSLIST.ORG (mailto: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 (mailto: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 (mailto:ARSList@arslist.org) https://mailman.rrr.se/cgi/listinfo/arslist (https://mailman.rrr.se/cgi/listinfo/arslist) -- Kelly Logan | Senior Consultant 313-651-7169 (javascript:false) | kelly.lo...@raptek.com (mailto:kelly.lo...@raptek.com) RAPID Technologies www.raptek.com (http://www.raptek.com/) -- ARSList mailing list ARSList@arslist.org (mailto:ARSList@arslist.org) https://mailman.rrr.se/cgi/listinfo/arslist (https://mailman.rrr.se/cgi/listinfo/arslist) -- ARSList mailing list ARSList@arslist.org (mailto:ARSList@arslist.org) https://mailman.rrr.se/cgi/listinfo/arslist (https://mailman.rrr.se/cgi/listinfo/arslist) -- Kelly Logan | Senior Consultant 313-651-7169 (javascript:false) | kelly.lo...@raptek.com (mailto:kelly.lo...@raptek.com) RAPID Technologies www.raptek.com (http://www.raptek.com/) -- ARSList mailing list ARSList@arslist.org (mailto:ARSList@arslist.org) https://mailman.rrr.se/cgi/listinfo/arslist (https://mailman.rrr.se/cgi/listinfo/arslist)
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
