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:          <http://www.softwaretoolhouse.com/> 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] On Behalf Of Jason Miller
Sent: December-08-17 1:00 PM
To: ARSList <arslist@arslist.org>
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.

 

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 <michael.ga...@caretech.com 
<mailto:michael.ga...@caretech.com> > 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 <lj.longw...@gmail.com 
<mailto: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 
<mailto: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 <mailto: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 
<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





 

-- 

Kelly Logan | Senior Consultant

313-651-7169 <tel:(313)%20651-7169>  | kelly.lo...@raptek.com 
<mailto:kelly.lo...@raptek.com> 

 

RAPID Technologies 

 <http://www.raptek.com/> www.raptek.com


--
ARSList mailing list
ARSList@arslist.org <mailto:ARSList@arslist.org> 
https://mailman.rrr.se/cgi/listinfo/arslist

 


--
ARSList mailing list
ARSList@arslist.org <mailto:ARSList@arslist.org> 
https://mailman.rrr.se/cgi/listinfo/arslist





 

-- 

Kelly Logan | Senior Consultant

313-651-7169 <tel:(313)%20651-7169>  | kelly.lo...@raptek.com 
<mailto:kelly.lo...@raptek.com> 

 

RAPID Technologies 

 <http://www.raptek.com/> www.raptek.com


--
ARSList mailing list
ARSList@arslist.org <mailto:ARSList@arslist.org> 
https://mailman.rrr.se/cgi/listinfo/arslist

 

-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Reply via email to