Again thanks for the help, *The problem:* We found in the /tmp/arDBError.log the error *The value(s) for this entry violate a unique index that has been defined for this form (ARERR 382) User logins must be unique* This lead us to look at the user_cache table and the user_cache table showed multiple entries in the USERNAME field that are not unique. *The Solution:* We removed the duplicates from the table and ran the install and it completed with out any errors.
This solved the installation problem but now we have ran into a nother issue when the ARS Server daemon tries to start, I will open a new thread on that if we can not resolve. Gary Dries T-Mobile On 1/4/07, Axton <[EMAIL PROTECTED]> wrote:
** Find the error logs. do a 'ls -latr' to see what was updated last in the tmp directories. Make sure you check in /var/tmp /tmp /usr/tmp. There should be additional logs that give more of an idication as to what failed. Axton Grams On 1/4/07, Gary Dries <[EMAIL PROTECTED]> wrote: > > ** Thanks All good stuff Axton > > yes we did confgure the 10g enviroment vars prior to the upgrade, as > stated in the install manual. > > We have been going through the sql log and did find where it updated the > control table changing the dbversion several times up to 21, but it does not > post any errors after that, it reads that it ended normally after creating > updating and dropping a support_file and user_cachey22 table. > > we will look for the core files and post if we find anything unusual. > > Thanks again, > > any other input from anyone is always helpful. > > On 1/4/07, Axton <[EMAIL PROTECTED]> wrote: > > > > ** Read the logs located in /tmp or /var/tmp or /usr/tmp (arsql.log, > > ardberror.log, arerror.log , etc.). These should give an indication > > as to the cause of the problem. > > > > Did you configure the 10g environment variables prior to running the > > upgrade installer? > > > > Look for any core files in either the install media dir, ar install > > dir, or tmp dirs. > > > > In the arsql.log, it should be evident that the upgrade installer > > stages the upgrade, moving from 5.1 (not sure schema version), to 20, > > to 21, and finally to 22. Something between these hosed up. The logs > > should tell you what. > > > > Please consider posting the solution you find on arswiki: > > http://arswiki.org/wiki/index.php?title=ARS_7.0_Topics#Installation_Issues > > > > > > Axton Grams > > > > On 1/4/07, Gary Dries <[EMAIL PROTECTED] > wrote: > > > > > > ** All, > > > We are upgrading both ARS and the DB and ran into a dbVersion > > > error. I have seen a couple of entries in on this list for this issue but > > > not for the same scenario. > > > > > > Platform Solaris SunOS 5.9 > > > DB upgrade from 9.2.0.5 using the 8.1.7 client > 10.2.0.2 using the > > > 32 bit 10gR2 client lib > > > ARS 5.1.2 patch 1313 > 7.00.01 installing as NON-ROOT no UNICODE > > > > > > The install fails at Stage 5 starting the ARS Server with the error > > > "The database is not the expected version (may need to run upgrade > > > program) (ARERR 36)" > > > > > > Using SQL Plus We checked the dbVersion > > > SQL> select dbversion from control; > > > DBVERSION > > > ---------- > > > 21 > > > > > > the select returned DBVERSION 21 referring to AR Server version > > > 6.03.00 > > > when it should be DBVERSION 22 for ARS Server version 7.x > > > > > > Any Help would be greatly appreciated > > > > > > Gary Dries > > > T-Mobile > > > __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___ > __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
