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:[email protected]] On Behalf Of Roger Justice
> Sent: Monday, April 12, 2010 9:48 AM
> To: [email protected]
> 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 <[email protected]>
> To: [email protected]
> 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"
