Thanks for this. Turns out the problem was a known error. (And yes we did have archiving switched on)
"This has been identified as a defect with the upgrade from 6.3 to 7.5p1 on Solaris servers with an Oracle 10 database." The workaround was to empty the column, alter it: ALTER TABLE SCHEMA_ARCHIVE MODIFY (archiveFromForm NUMBER(15)); And then reload the data back in again. And then it was fine. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W Sent: 25 June 2009 22:47 To: [email protected] Subject: Re: Upgrade to 7.5: ORA-01439: column to be modified must be empty Actually it looks like it is complaining that there is data in the SCHEMA_ARCHIVE.archiveFromForm column. Do you have archiving turned on for any forms in the 6.3 server? What the installer looks to be doing is to be changing the column type for that column, and Oracle can't do it while there is data in that column. I wonder if 6.3 used to store the form name and 7.5 will store the form ID (since it says it is changing the column to a number). Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Axton Sent: Thursday, June 25, 2009 10:12 AM To: [email protected] Subject: Re: Upgrade to 7.5: ORA-01439: column to be modified must be empty What does the following return from sql*plus: desc SCHEMA_ARCHIVE What version are you upgrading from? Axton Grams On Thu, Jun 25, 2009 at 4:36 AM, Ross, Isabel (Access LLP)<[email protected]> wrote: > Hello > > I'm trying to upgrade to 7.5 (patch 001)and am getting the following > severe error: > > com.bmc.install.product.arsuitekit.platforms.arsystemservers.arserver. > AR > ServerOracleManageUpgrad eDatabaseTask > LOG EVENT {Description=[[SQLERROR] [DESCRIPTION] Failed to upgrade the > database schema],Detail=[[SQLERRORCODE]=0 [SQLMESSAGE]=Failed to run > SQL statement [ALTER TABLE SCHEMA_ARCHIVE MODIFY ( archiveFromForm > NUMBER(15) )] Due to [ORA-01439: column to be modified must be empty to > change datatype > > As well as upgrading Remedy, we're also moving to virtualised server > zones so the set-up we have is: > > Application server: Solaris 10, Oracle client 10G > Database server: Solaris 10, Oracle enterprise edition 10G > > I have a copy of our Remedy 6.3 database on the new server, and I'm > installing this as an upgrade. > > I'm not sure if the error message is referring to table T15. If it > is, then that's the table for the Alert List. > > Also had one other severe error but I don't think this one is stopping > the installation from completing > > Severe: > LOG EVENT {Description=[LANG variable not set Could not determine the > LANG variable setting.]} > > Any thoughts? > > Thanks! > > Isabel Ross > Senior Analyst Programmer > Applications and Business Solutions > > 112 Ingram Street > Glasgow > G1 1ET > > Phone: 0141 276 0937 > Email: [email protected] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" ***Disclaimer**** This e-mail and any attachments are for the intended addressee(s) only and may contain confidential and/or privileged material. If you are not a named addressee, do not use, retain or disclose such information. This email is not guaranteed to be free from viruses and does not bind Access in any contract or obligation. SERVICE GLASGOW LLP trading as ACCESS Registered in Scotland. No: SO301705 Registered Office:112 Ingram Street, Glasgow, G1 1ET _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
