Roy,
Looks like you are well on the way to fixing it.
You'll probably need to delete some meta-data in the user tool to recover.
I always use unique field IDs from my preferred range when creating new
attributes so I haven't personally had this problem in production. I only
saw it in development when I was playing after I noticed a previous
developer had added a few attributes with field ids in the Remedy reserved
range.
Best of luck.
Cheers
Peter
Ashcraft, Roy W. writes:
Peter,
I let the class manager pick the Field ID's, it chose the same Field
ID's as two custom fields on the AssetBase class for fields added to the
System class, causing no end of problems.
Talked to Remedy support, who said encouraging things like "I've never
seen that before..." They have logged a defect and are trying to figure
out how the class manager did what it did. They gave me two
possibilities to correct the issue, delete the corrupt fields from
AssetBase, then recreate specifying field id's for both the AssetBase
fields and the System fields. Failing that (which ran over night and did
nothing), restore to a prior backup. Luckily, this isn't a production
system, yet...
Really don't think the "Do you have a good backup prior to making the
change?" line works with production systems. I'm in development, so I
lose a day's worth of work restoring from backup, but in production you
would lose live data that you cannot necessarily replace, at least not
in a decent time span. Rich did mention that CMDB 2.0 deals with issues
similar to this (though, not identical) better, but that isn't an option
for us for at least another year.
Thanks,
Roy
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Romain
Sent: Tuesday, December 19, 2006 3:48 AM
To: [email protected]
Subject: Re: CMDB Woes
Roy,
When you added the fields did you specify unique field IDs for each one?
On CMDB 1.1 P3:
If you add a field to a class then the database name and label on the
BMC join form of any fields in regular classes below it with the same
field id will be changed. The fields themselves in the regular forms are
not, however, touched. The class manager then shows the two fields with
the same ID in the metadata but you can't correct this with just the
class manager or cmdbdriver.
The modification you see seems to be in the other direction (system
changes affecting a higher class) which I haven't seen before.
Cheers
Peter
Ashcraft, Roy W. writes:
I've been fighting the CMDB for weeks now. The latest problem has just
frustrated me into not being able to think clearly.
Platform:
Win 2k3 Server, ARS 7.0.00
ITSM 6, CMDB 1.1
The customer wanted several fields added to all asset forms. Added
these through the class manager, all went well. In addition, the
customer wanted 2 additional fields on all system forms (computer
system, database system, etc.), added these through the class manager.
When I went to the asset forms to add these fields and make them
visible for data input, I discovered that the CMDB class manager had
updated two of the previously created fields on asset base with the
name/label of the fields that I attempted to add to the system class.
What I need to do now, is return the fields added to the asset base
class to what they were prior to this and someone add the 2 new fields
to the system class.
Has anyone run into a similar situation? Does anyone know how to fix
this without "restoring a prior database backup". The "backup the
database prior to any change to the CMDB class manager" will not be a
long-term viable option as you can not always block production data
for any length of time and will lose data updates when restoring to a
previous point. Wouldn't be bad if the CMDB updates were quick, but
I've seen them take from 10 minutes to 7 hours to complete.
Thanks,
Roy
Roy Ashcraft
Systems Analyst
SAIC
[EMAIL PROTECTED]
(402) 293-5218
______________________________________________________________________
_________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
ARSlist:"Where the Answers Are"
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
