Sorry. I do NOT want to open a can of worms here, but I do this regularly (and in minutes), through the API, and to all forms including "root requests", CMDB, and every aspect of Foundation data.
The only SQL one would need is the resetting of the next id (which I generally don't do as I don't tend to care what request ids get assigned). These days they tend to be hidden anyhow. The root requests ids (Incident Number etc) are NOT request ids '1' and so the API can also be used there - though it's nice if the "Incident Number" matches the Request ID. This will not be the case for long in a production environment BTW. So, I tend to have systems with Operating Companies not starting at 1, Support Groups Ids starting at 500ish, and very few tables starting at IDs of 1. As for referential integrity (presumably you mean not leaving hanging records) you are relying on Remedy workflow. Whilst the newer versions are better, there are still a lot of hanging records left, so yes, understanding (ie analysis) of the data structures is important. I always delete in bottom up order just for the sake of performance because there is no way to inhibit delete filters through the API. A delete of say 1000 Change templates would take hours top down but minutes bottom up. Workflow still fires but with no effect. Cleansing is trivial. I expect you are way under in your "Analysis" estimate though :) Perhaps years rather than days. Especially given some of the convoluted ways some tables are used and the fact that very little is documented. 'Nuff said on the matter. Cheers Ben Chernys www.softwaretoolhouse.com -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of J Lander Sent: May-16-13 06:46 To: arslist@ARSLIST.ORG Subject: Re: [URGENT] - Need to clean up all INC/CR/PBI/SR records and set the counter from xxxxxxx01 What you are asking for is possible but a very large undertaking. It also relies on the person having decent SQL and Remedy ITSM skills. The suggestions from others in this post are worth considering. I have performed the data cleanse a few times in the past and it is not a pretty job. It involves performing thorough in-depth analysis of every single form using SQL (to identify test data both for main forms and their supporting ones) and documenting what exactly will be removed and what needs to stay. Forms which have a customer facing Ticket ID (e.g. Incident, Problem, Change etc) would have their counters reset to a value of 1 in the arschema table but the rest would not. You would also need to take a full backup of the database before any data is deleted (obviously). Foundation and Configuration forms should not have any data removed. Please note that even if you did perform the above, it takes days to do. The analysis itself is probably 2-3 days. The cleansing is also a further 1-2 days. Most of it also needs to be done via the User Tool/Mid-Tier. This allows for any workflow to fire that keeps referential integrity. What you should have done, and is the recommended best practise, is to backup the database when it was ready for testing, perform testing, remediate defects, test remediations, export workflow/data, restore database, apply fixes, backup database, shake test, cancel shake test tickets, backup database, move on to next testing phase. This way you would always have had a database which contain very few tickets but all config, fixes. customisation etc. It's a little cumbersome, but it prevents the issue you are facing now. Cheers, J _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3336 / Virus Database: 3162/6325 - Release Date: 05/15/13 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
smime.p7s
Description: S/MIME cryptographic signature
