Anytime you want to handle a “Tree” of related records, Meta-Update is your tool.
Queries are cascaded on each other so that one root request and all its dependencies are handled before the next root request is handled. With Meta-Update, this can be done so that when moving a single tree to other servers, the linking values are changed on the new servers (yes request ids are still referenced within ITSM) so that the tree is transported to another server intact and functioning . As BMC once said when I asked a customer for some sample ITSM 6 Changes, Tickets, CIs and transferred them across to 7, “You mean that is possible?” Yes. It is possible. You can, say, archive all root requests older than x and move them and all their dependencies such that they are still connected on a new environment. You can control things like replicating (but not archiving) dependent CIs etc. Cheers Ben Chernys Senior Software Architect Description: logoSthInc-sm Canada / Deutschland / Germany Mobile: +49 171 380 2329 GMT + 1 + [ DST ] Email: <mailto:Ben.Chernys%20_AT%20_%20softwaretoolhouse.com> Ben.Chernys _AT_ softwaretoolhouse.com Web: <http://www.softwaretoolhouse.com/> www.softwaretoolhouse.com Check out Software Tool House's free Diary Editor. 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. <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of patchsk Sent: January-24-12 21:19 To: [email protected] Subject: Archiving strategy on ITSM 7.6 + ** We just started to looking at archiving our production data. We are currently in ITSM 7.6.03. With so many related forms to main forms, it would be tricky and take significant effort to properly draw the archiving plan like which forms need to archived in which order so that relationships are carried over so that a closed incident will be moved to a different server or a different form with all of its relationships in tact. Anyone done this already, if so can you provide a few details on the strategy you followed. DSO is another option we are looking at it but have not made decision yet. We can not use DB level replication because if we delete a record in production then it will delete it from replicated database also. Seems like from BMC knowledge base it is not supported and cannot provide any guidelines. But we cannot just keep storing the data in production. _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<image003.jpg>>
