We had a similar problem with the User form after upgrading to 7.1. Support asked if we had customized our User form, which we had. They said to back up the data, download a fresh form definition, and delete and re-import the form and data. That sounded scarey to us.
Instead we looked at the message and queried the db for the fieldname of the column in question. Then we copied and deleted that field, saved the form, pasted the field back into the form and saved again. We kept doing that till we no longer got the message. That seems to have fixed the problem. Apparently you are not supposed to customize the User or Group form, but we customized ours six years ago before we knew about the rule. Dwayne Martin James Madison University ---- Original message ---- >Date: Sat, 20 Oct 2007 15:53:37 -0500 >From: strauss <[EMAIL PROTECTED]> >Subject: Re: Help with ARERR 552 >To: arslist@ARSLIST.ORG > > ** > In spite of my recent experiences with Migrator 7.1 > between 7.1 servers when the target server is not in > development cache mode, if I was in this situation I > would try to migrate the Group form from a valid > 7.0.01.004 installation to the one that > is experiencing problems. Migrator is the only tool > I have used that will reliably ADD fields - columns > to a table (don't try to remove them), without > risking the data or directly editing the form. I > have moved data records successfully with it as > well, if you had to go in the other direction. In > this case you just need the columns added back to > the table. You could even do it from a def file of > the Group form, if you could get a good one from > another server. The only error you might get would > be when it tries to update the arsfields table > afterwards and finds the existing column ids, but if > it fixes the Group table you should be okay - > migrator should not create a mismatch between column > ids since it maintains the source id unless you tell > it to use a new one. It's one more thing to try... > > Christopher Strauss, Ph.D. > Remedy Database Administrator > University of North Texas Computing Center > http://itsm.unt.edu/ > > ------------------------------------------------ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of David > Sanders > Sent: Saturday, October 20, 2007 1:37 PM > To: arslist@ARSLIST.ORG > Subject: Re: Help with ARERR 552 > > ** > > Sorry if this has already been suggested, but have > you tried importing the Group form from a def > file? If you go to your ARServer installation > directory, the Group form def is located in the > ...\ARServer\InstallForms\en directory. > > > > If you have to delete the Group form, the server > should remain operable as it will use the entries > in the group_cache table (until the server tries > to recache). > > > > HTH > > > > David Sanders > > Remedy Solution Architect > > Enterprise Service Suite @ Work > > ========================== > > ARS List Award Winner 2005 > > Best 3rd party Remedy Application > > > > See the ESS Concepts Guide > > > > tel +44 1494 468980 > > mobile +44 7710 377761 > > email [EMAIL PROTECTED] > > > > web http://www.westoverconsulting.co.uk > > > > ---------------------------------------------------- > > From: Action Request System discussion > list(ARSList) [mailto:[EMAIL PROTECTED] On > Behalf Of Joe D'Souza > Sent: Saturday, October 20, 2007 9:41 AM > To: arslist@ARSLIST.ORG > Subject: Re: Help with ARERR 552 > > > > Then maybe restoring the whole table as such is > not a good idea. What might be a good idea though > is to restore only the T table that belongs to the > Group form. Before that though take a backup of > the data contained in the T table. After restoring > just the T table, restore the data contained > within the T table. I had done an operation > similar to that with the help of an Oracle DBA in > the past. So if you are on Oracle, this is a > possibility. > > > > After that it will be a good idea to run the AR > System upgrade, so just in case there is still a > problem with the Group form, the upgrade script > may take care of it - depending on whether the > script is designed to overwrite the user and group > form on every upgrade. > > > > OR maybe you should try running that upgrade > script in the first place before even the > restoration of the table as described above.. > > > > Cheers > > > > Joe D'Souza > > -----Original Message----- > From: Action Request System discussion > list(ARSList) [mailto:[EMAIL PROTECTED] > Behalf Of [EMAIL PROTECTED] > Sent: Friday, October 19, 2007 9:07 PM > To: arslist@ARSLIST.ORG > Subject: Re: Help with ARERR 552 > > ** > > Unfortunately, all of our 7.0.1 backups have > this problem, since it occurred during the > upgrade process. Our previous version db > backups are two weeks old and loosing that much > data is not an option, not too mention the > amount of post upgrade work we have done during > the last two weeks to accommodate for 7.0.1 > idiosyncrasies. > > This is one we have to fight through, I was > hoping that there would have been someone who > has had this happen and knew of a fix. Seems > like BMC/Remedy would have some type of DB tool > which could validate and correct the DB > structure if problems were found during the > validation, I guess that would be WAY too much > to ask for though. I would even be happy if the > Admin tool, which is more than happy to tell you > there is a problem with the form, would perform > the correction on save or at least give you the > option of performing the correction. > > Looks like I get to learn more about the Remedy > DB structure than I wanted too. I'll have to > study up over the weekend and go in Monday to > perform brain surgery. > > Thanks, > Dave > > ----- Original Message ---- > From: Joe D'Souza <[EMAIL PROTECTED]> > To: arslist@ARSLIST.ORG > Sent: Friday, October 19, 2007 3:20:08 PM > Subject: Re: Help with ARERR 552 > > ** > > You will loose access to your system to do > anything further if you delete the group form... > > > > Restoring your last known good backup of the > database is your best and fastest option. Any > other option would be very time consuming > (attempts to build the T table by altering it to > include the missing columns etc..). Not > impossible but might take even an expert Remedy > developer a lot more than 15 or 20 minutes that > restoring a DB backup would take.. > > > > Cheers > > > > Joe D'Souza > > -----Original Message----- > From: Action Request System discussion > list(ARSList) [mailto:[EMAIL PROTECTED] > Behalf Of [EMAIL PROTECTED] > Sent: Friday, October 19, 2007 4:23 PM > To: arslist@ARSLIST.ORG > Subject: Re: Help with ARERR 552 > > ** > > Yes, we do have a backup of the pre-upgrade > database (we still have the pre-upgrade > database server in pristine condition). While > restoring the database would provide a means > to recover the data in the Group form, it > would not resolve the error with the 7.01 > Group form. While it would be possible to > recover the Group form data and then delete > the current Group form and Reimport a valid > Group form, I'm not sure that it is possible > to delete the Group form and maintain an > operational system. > > Like you, we had this occur on a test upgrade > to 7.0 to the User form. The end result was, > because it was a test upgrade, to dump the > system and redo the upgrade process. However, > with 7.0 this happened every time we tried the > upgrade, thus the wait for 7.0.1 for the > upgrade. During testing with 7.0.1 this error > did not occur, so we thought we were out of > the woods on it. > > Thanks, > Dave > > ----- Original Message ---- > From: Rahul AR User <[EMAIL PROTECTED]> > To: arslist@ARSLIST.ORG > Sent: Friday, October 19, 2007 2:02:06 PM > Subject: Re: Help with ARERR 552 > > ** Did u take the database backup before the > upgrade?? If yes then restore the backup on > some other database server and import the > table from this restored database to the > existing database. I'll again remind you to > take a database backup before proceeding with > the steps as mentioned above. > > On 10/20/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > ** > > Anyone have a recommendation for this. > > When accessing the Group form we receive the > error "ARERR 552 Failure during SQL operation > to the database: Invalid column name 'C179', > (SQL Server 207)Invalid column name 'C121', > (SQL Server 207)Invalid column name 'C120', > (SQL Server 207) > > This error prevents us from viewing, creating > or modifying records on the Group form. > > The fields exist in the 'field' table but do > not exist in the 'T9' table. All efforts to > resolve this through the Admin tool have been > unsuccessful. My best guess on cause would be > a problem with the form creation/import during > our database upgrade to 7.0.1. I would try to > manually create the fields in the T table, but > do not want to cause more issues than what I > have. > > Equally unsuccessful was to open a high impact > ticket with BMC Support over 24 hours ago > (ISS03190758). They have been unresponsive > and have failed to meet the Fast-Track SLA. > (If anyone from BMC is monitoring the list any > assistance would be greatly appreciated.) > > Windows 2003 Server / MSSQL 2000 / BMC Remedy > AR System 7.0.1 P4 > > Thanks in advance, > Dave Fincher > > __20060125_______________________This posting was > submitted with HTML in it___ > __20060125_______________________This posting was > submitted with HTML in it___ > > __20060125_______________________This posting was > submitted with HTML in it___ Dwayne Martin Computing Support James Madison University _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
