Hi, If you are using RRR|Chive to copy data to a form where records already exists, you can use 'entryidmode' to make sure they do not overwrite.
entryidmode=NEW will create new ids for the records. entryidmode=+10000 will add 10000 to the old entry-id before it is merged entryidmode=XYZ000000000000 will change the prefix to XYZ before merge In all these cases you will get a problem if the entry-id-field of your form is used as a foreign key in other forms. If you know the places where the entry-id is used as foreign key, I have an unpublished tool that can change the key in the child-forms based on the log-file of RRR|Chive. Let me know if you need that! Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * 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. > Using the DMT to import your data will result in mis-matches between > foundation data group IDs or other record IDs and those contained in your > ticketing data. We found it to be useless for moving any data that > depends on links to existing records, since it creates new records from > scratch from the spreadsheet data in whatever order it wants, resulting in > record IDs that differ from your source server. It's like trying to take > custom DTS packages in SQL Server written against one AR Server at the > T-table level, and move them to another AR Server installed separately; > none of the T-table numbers line up! > > Looking at a typical HPD:Help Desk record, there are several Group IDs, > several Support Group IDs, a Person ID and a Site ID, all stored in the > record. If you use DMT to recreate your foundation and customer data, > none of these field values will connect the Incident to the correct > supporting records. > > We have moved all of our foundation data over from ITSM 7.0.03.009 to ITSM > 7.6.00.001 using rrrchive in overwrite mode for most of it... and the > links are retained because we are slamming our 7.0.03 data over the OOTB > 7.6 data (for example, some of the Calbro data will get replaced with My > Company data). Ticketing data followed, and all of the association data > appears to be working because we have forced the retention of all record > ID information. In any table that we wanted to keep some of the OOTB data > but add our custom data, we had to export to .arx and use the Import Tool > since we had little success with rrrchive in any mode except overwrite. > For example, here are the settings for two we had to import: > > GROUP: > Replace Old Record with New Record > Custom Fields - on "Group Name" > Use First Matching Request > Checked: > Make Non-Core Required Fields Optional > Suppress Filters > Suppress Field Default Values > Import Records with Too Many Fields > Import Records with Too Few Fields > > COM:Company > Update Old Record with New Record's Data > (Calbro and Invention get overwritten) > Request ID > Use First Matching Request > Checked: > Make Non-Core Required Fields Optional > Suppress Filters > Suppress Field Default Values > Import Records with Too Many Fields > Import Records with Too Few Fields > > One of the problems we hit was that if you install the Product Catalog and > import data when setting up Atrium Core 7.6, it brings in thousands of > companies and related data that will conflict with your custom company > organizational data, especially if you are multi-tenancy like we are and > have a lot of companies. We had to reinstall AtriumCore without the > product catalog data in order to leave room for our 7.0 foundation data, > and we will add it later. > > We think we got a good move of all foundation and ITSM (ServiceDesk and > Change Management) data, as well as Kinetic Request, moving it at the > table level (just over 100 tables have data). We don't have Asset Mgmt > until we get to 7.6, and our CMDB is empty, so it isn't as much data as > you might have. Kinetic Request and Calendar were also moved successfully > at the table level (37 tables), but SLM has proven harder to figure out > and we are still trying to use the SLM export-import tools. We have > already found a major bug in the export where at different patch levels of > the SLM 7.1 app, different forms of a flagword were used in the > SLM:SLAAssociation form, and the presence of the earlier one (SLM_CONTRACT > instead of SLMCONTRACT) prevents the correct export of Service Agreements > and related objects. We still have to re-visit the notification subsystem > - BMC rebuilt it enough that entire tables were deprecated, but these are > pass-through tables so it may still work. > > We are still working on this on our test 7.5/7.6 server, and still have to > (1) move the same data from production 7.1/7.0 server to the new > production 7.5/7.6 server, and (2) figure out which tables have data that > must be re-copied just before cutover since it will have changed (tickets, > work info, association records, etc.). It is complicated by the fact that > we have added a fair number of custom fields to HPD:Help Desk, and those > fields must be migrated to the 7.6 app before you can move the data. We > are recording everything in a spreadsheet as we go, and it will also be > our roadmap for data to move again during the cutover. > > This is probably doing it the hard way, but our tests of upgrading last > year were all relatively unsuccessful at the application level due to BMC > re-writing modules that we had customized, plus the file folder lay down > of executables on the server is different between a 7.1/7.0 install and a > 7.5/7.6 install. An upgrade is a scrambled combination of the two, making > file maintenance a mess and confusing the plugin systems when you add > modules like Asset Mgmt and they end up trying to use different path > constructs. From what I saw, I would not want to put an upgraded app into > production unless I could successfully restore it on a server with a clean > install of the 7.6. apps, among other things. We are continuing to move > forward with mapping and moving data at the table level, instead. > > Christopher Strauss, Ph.D. > Call Tracking Administration Manager > University of North Texas Computing & IT Center > http://itsm.unt.edu/ > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Roger Justice > Sent: Monday, April 12, 2010 9:48 AM > To: arslist@ARSLIST.ORG > Subject: Re: Import Production Data into Test Environment? > > ** The DMT is installed automatically with ITSM 7.6 start with the > spredsheets provided to determine what foundation data you can export and > then using DMT import. Some of your foundation data may need to be > imported without the DMT. > > -----Original Message----- > From: Hulmes, Timothy W Mr CTR US USA IMCOM <timothy.hul...@us.army.mil> > To: arslist@ARSLIST.ORG > Sent: Mon, Apr 12, 2010 10:42 am > Subject: Import Production Data into Test Environment? > > We are in a tough bind at this point. Thought I would throw out a bone > > to see if anyone knew of an easy way to complete this action. > > > > Here is the situation, we have a production environment of: > > ARS 7.5 Patch 4 > > CMDB 7.6 Patch 1 (Only thing we don't have is Product Catalog > > installed) > > ITSM 7.0.03 Patch 9 plus compatibility path 9000 > > SLM 7.6 > > > > In our Test environment we want to get to > > ARS 7.5 Patch 4 > > CMDB 7.6 Patch 1 > > ITSM 7.6 Patch 2 > > SLM 7.6 Patch 1 > > > > Our database is SQL 2005. If we use a copy of our production database > > to upgrade we get error because of ITSM-DSL 7.0.03 Patch 9 gives us > > error during the CMDB upgrade, which is why we don't have Product > > Catalog in production. We can't upgrade to ITSM without Product > > Catalog. > > If we do a complete fresh install in test we are good but then we don't > > have any of our foundation data. We don't really want to have to > > rebuild or manually import all of that data if it can be avoided. > > > > We have a ticket in with BMC but haven't achieved success yet. > > > > We need to begin testing our process against ITSM 7.6 ASAP, anyone have > > any ideas of the fastest way to get that data if we do a fresh install > > instead of upgrading against the production database? > > > > Tim > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org<http://www.arslist.org/> > > attend wwrug10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the > Answers Are" > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"