Here is my account of what happens. The import will not work to solve
the problem.
<sql>
SQL> ed
Wrote file afiedt.buf
1* select schemaid, numfields, name from arschema where name = 'zTestChange'
SQL> /
SCHEMAID NUMFIELDS NAME
---------- ---------- --------------------------------------------------------
1555 9 zTestChange
SQL> update arschema set numfields=10 where schemaid = 1555
2 /
1 row updated.
SQL> commit
2 /
Commit complete.
SQL>
</sql>
<unix>
[EMAIL PROTECTED]:/path/to/remedy/bin> arsignal -r rm00d70
[EMAIL PROTECTED]:/path/to/remedy/bin> tail -f ../db/arerror.log
...
Tue May 8 12:09:59 2007 390600 : The form definition file field
count does not match number of fields in the file (ARERR 403)
Tue May 8 12:09:59 2007 zTestChange
<unix>
Then the form is no longer visible in the admin tool. If I reset the
changes then the form works.
If I create a def for a form with the same name, import (override), I
get this error:
The value(s) for this entry violate a unique index that has been
defined for this form: (ARERR 382)
The following item was not imported: zTestChange (ARERR 55)
I guess the bigger question here is, how did it get to this sate in
the first place? Then undo those changes.
As to whether or not the safeguard value is based partly on the
numfields, it is. I basically added a field to the form, below the
nextfieldid value, saved, then compared the values in arschema:
NAME
SCHEMAID SCHEMATYPE TIMESTAMP
OWNER
LASTCHANGED
COREVERSION NUMFIELDS NUMVUIS
DEFAULTVUI
NEXTID NEXTFIELDID MAXSTATENUMS UPGRDVERSION
SAFEGUARD
HELPTEXT
CHANGEDIARY
OBJPROP
VERSION
SMOBJPROP
<before new field>
zTestChange
1555 1 1178640455
axton
axton
2 9 1
Default Admin View
1 536870912 5 0
WosBrZH43yvSDLdJFsVzdtjxVm6gtPYPJHfcEwyq4Rf0E646e88aq0uPD2wqEtgevBuVOi4J2zHZ
c2NCZcnzyZOLR0Xv2V4g
</before new field>
<after new field>
zTestChange
1555 1 1178641541
axton
axton
2 10 1
Default Admin View
1 536870912 5 0
sG8HNsIuRFxKqnoxjsFsWAezUNodZRm4Vle3aErCK9a50jtaqNPv7CfpYvcjiAKLalNjxE1V1XcC
vj9NOak1QIihtoM5VKXM
</after new field>
I guess it is possible that it is based on login name and time and not
the numfields, but I don't have the access to verify this here.
Axton Grams
On 5/8/07, Kendhammer, Mike <[EMAIL PROTECTED]> wrote:
Hi Axton,
Whether trying to import one of the forms (from a recent .def file) via
Migrator or the Admin Tool, I get the following error...
The value(s) for this entry violate a unique index that has been defined for
this form: (ARERR 382)
The following item was not imported: CMDB:Join1_AppInstInfoAppAppDep (ARERR 55)
Mike
-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
On Behalf Of Axton
Sent: Tuesday, May 08, 2007 10:51 AM
To: [email protected]
Subject: Re: Manual Removal of Forms from Database
Then that is not part of the value used to generate the checksum,
which would make sense since it changes continuously. I can't say
definitively which columns are used to generate the checksum, but I
would imagine it entails all columns that make up the object
definition (i.e., anything you will find in a def file).
I am curious as to the results for the OP though.
Axton Grams
On 5/8/07, Jarl Grøneng <[EMAIL PROTECTED]> wrote:
> I´m I updated the main chg form in ITSM 7 in arschema to start over
> with nextid, no problem with that.
>
> --
> Jarl
>
> On 5/8/07, Axton <[EMAIL PROTECTED]> wrote:
> > If you update arschema, the record will have an invalid checksum in
> > the safeguard column, and you will be in the same boat. You used to
> > be able to do this with 5.x servers and earlier, but since 6.x, you
> > can no longer take this approach.
> >
> > Axton Grams
> >
> > Name Null? Type
> > ------------ -------- -------------
> > NAME NOT NULL VARCHAR2(254)
> > SCHEMAID NOT NULL NUMBER(15)
> > SCHEMATYPE NOT NULL NUMBER(15)
> > TIMESTAMP NOT NULL NUMBER(15)
> > OWNER NOT NULL VARCHAR2(254)
> > LASTCHANGED NOT NULL VARCHAR2(254)
> > COREVERSION NOT NULL NUMBER(15)
> > NUMFIELDS NOT NULL NUMBER(15)
> > NUMVUIS NOT NULL NUMBER(15)
> > DEFAULTVUI NOT NULL VARCHAR2(254)
> > NEXTID NOT NULL NUMBER(15)
> > NEXTFIELDID NOT NULL NUMBER(15)
> > MAXSTATENUMS NOT NULL NUMBER(15)
> > UPGRDVERSION NUMBER(15)
> > SAFEGUARD NOT NULL VARCHAR2(254)
> > HELPTEXT CLOB
> > CHANGEDIARY CLOB
> > OBJPROP CLOB
> > VERSION VARCHAR2(32)
> > SMOBJPROP CLOB
> >
> >
> > On 5/8/07, Kendhammer, Mike <[EMAIL PROTECTED]> wrote:
> > > Thanks for everyone's comments and suggestions.
> > >
> > > I think I have a plan and that is to follow KM-000000006374 as Supreet
> > > suggested and also BMC support suggested.
> > >
> > > My hope is that if I update the numfields column in the arschema table
> > > for each of the 31 join forms that I have that have gone bad, stop and
> > > re-start the arsystem, then these forms will become visible in the admin
> > > tool once again, and then I can at least delete them the standard way.
> > >
> > >
> > > Now I just need to figure out when to do this as I am leaving for DC
> > > tomorrow morning (a bus trip with 90 plus 5th graders!) and won't get
> > > back until Sunday, so looks like I won't be able to get to it until next
> > > week sometime.
> > >
> > > I think the system should be fine until then...
> > >
> > > Thanks!
> > > Mike
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Action Request System discussion list(ARSList)
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Richard Baird
> > > Sent: Tuesday, May 08, 2007 8:06 AM
> > > To: [email protected]
> > > Subject: Re: Manual Removal of Forms from Database
> > >
> > > Good call Axton. That's the approach I've taken in the past for this
> > > same
> > > kind of thing. You may still need to remove the record for the join form
> > > in
> > > arschema and the view for the form if they still exist though.
> > > Aradmin.exe
> > > may not let you do the .def import if these still exist, even though
> > > they
> > > don't show up in aradmin.
> > >
> > > This approach does mean considerably less "hacking" of the DB. Not sure
> > > if
> > > anyone mentioned this yet, but be sure the AR Service or daemon is
> > > shutdown
> > > before doing such surgery or you may end up with an even bigger mess.
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > > -----Original Message-----
> > > From: Axton [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, May 07, 2007 7:12 PM
> > > Subject: Re: Manual Removal of Forms from Database
> > >
> > > You may have better luck importing a def of the same form type and name
> > > into
> > > the server, then deleting that. That should keep your db clean if it
> > > will
> > > work.
> > >
> > > There are records in a lot of tables to clean up if you had any field
> > > fields, workflow, form views, etc.
> > >
> > > Axton Grams
> > >
> > > On 5/7/07, supreet gill <[EMAIL PROTECTED]> wrote:
> > > > Hi Mike,
> > > > Search for KM-000000006374 in the knowledgebase on the support site.
> > > > There is also a script attached to the KB for Oracle.
> > > > Regards
> > > > Supreet
> > > > --- "Kendhammer, Mike"
> > > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > > Without going into a long story here, I try to explain the
> > > > > aftermath...
> > > > >
> > > > >
> > > > >
> > > > > I have a number of Join forms that appear to have been corrupted.
> > > > > The view and corresponding record in the ARSCHEMA table exist, yet
> > > > > they do not appear in the Admin Tool. (Yes, I did check that the
> > > > > 'By Form'
> > > > > filter was set to All Forms...:-) ) They don't compile, thus
> > > > > underlying tables have been altered or are gone. I do see an error
> > > > > in the arerror.log file stating "The form definition file field
> > > > > count does not match number of fields in the file (ARERR 403)" then
> > > > > the form name.
> > > > >
> > > > >
> > > > >
> > > > > I need to know besides dropping the T and H tables and deleting the
> > > > > records from the ARSCHEMA table, what other tables need to be
> > > > > updated or dropped? It looks like records in many of the 'FIELD*'
> > > > > tables may need to be updated as well. I no longer need these join
> > > > > forms, thus I don't need to worry about restoring them.
> > > > >
> > > > >
> > > > >
> > > > > We are running ARS 6.3.0 patch 20 on HP-UX 11i/Oracle 9i.
> > > > >
> > > > >
> > > > >
> > > > > If anyone has gone through the process of manually
> > > > > removing tables
> > > > > within ARS, I'll like to hear your comments or see
> > > > > any notes/steps you
> > > > > may have or gone through to do it.
> > > > >
> > > > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > >
> > > > >
> > > > > Mike K.
> > > > >
> > > > > American Standard/Trane
> > > > >
> > > > >
> > > > >
> > > >
> > > ________________________________________________________________________
> > > ____
> > > ___
> > > > > UNSUBSCRIBE or access ARSlist Archives at
> > > > > www.arslist.org ARSlist:"Where the Answers Are"
> > > > >
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > >
> > > ________________________________________________________________________
> > > ____
> > > ___
> > > > 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"
> > >
> >
> >
_______________________________________________________________________________
> > 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"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
