Re: Upgrading from 7.3x to 9.x

It's document in the release notes that you use HPL using TCP/IP connection. >From: Doug McAllister <doug.mcallister@nospam.fmr.com> >To: informix-list@iiug.org >Subject: Re: Upgrading from 7.3x to 9.x >Date: Thu, 05 Oct 2000 16:02:40 -0400 >Reply-To: Doug McAllister <doug.mcallister@nospam.fmr.com> > >This is a multi-part message in MIME format. >--------------244A9D8009CD708F23E2D2E7 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >I just installed 9.21.fc2 on a Solaris 8 machine and uncovered a bug. >The High-Performance loader will NOT run. when I dropped back to 32-bit >mode (9.21.uc2) without changing any parameters and it ran fine. > >Jeff Larsen wrote: >> >> CAUTION!!! >> >> I just upgraded from 7.30FC7 to 9.21FC2 on Solaris 7 and >> have had significant difficulties, some of which are >> attributable to bugs in 9.2. On the bright side for you >> is that many of my problems were caused by the migration >> itself. A full export/import cycle would have been better. >> >> 1. In 9.x there is a new distinction between a "procedure" >> and a "function" a function returns a value, a procedure >> does not. In 7.x you created all of your routines using >> CREATE PROCEDURE. Any migrated procedures that return a >> value will get error 999 (Not implemented) if you try >> something like "update tabx set colx = my_procedure(coly)"; >> >> 2. There is a BUG in 9.21FC2 (not sure about other versions) >> on cascading deletes for tables migrated from 7.x. Cascading >> deletes fail and get an obscure error message (I forget the code number). >> For me the bug won't be fixed until December in 9.21FC4. Dropping >> and rebuilding the tables under 9.x will fix this however. >> >> 3. Explicit type casting may be required for some internal >> functions like mod() or abs(). I had some code that used >> mod(date_value - another_date_value, int_value) which gave me error 9700 >> (Routine ambiguous). Apparently 9.2 has multiple mod() routines >> with different argument type signatures. I had to alter >> my code to cast the date calculation as an INTEGER. >> >> 4. More type casting... In 7.3 you could do something like >> >> select * from tabx where datetime_col > (date_value + int_value);>> >> This code will not work in 9.2. You need to explicitly cast the >> expression to a date value such as... >> >> select * from tabx where datetime_col > date(date_value + int_value);>> >> 5. Some column names or aliases may get syntax errors if they match >> any of the large number of reserved words in 9.2. You need to use >> table.column or table_alias.column syntax in you select expressions >> to specify column names that match reserved words. Or for column aliases >> you need to use "select colx AS reserved_word_alias ....". You must >> use the "AS". >> >> 6. 9.21 does not communicate nicely with 7.x in distributed queries. >> If a 7.x session executes "select * from database@version9server:table", >> the 9.2 engine fails to realize it is talking to a 7.x server and sends >> it long table names and column names resulting in overwritten memory >> headers in your client sessions on 7.x. Quite often, this will result >> in an assertion failure and crash on the 7.x engine. I don't know >> when this bug will be fixed. My only option was to pull an all-nighter >> and upgrade 3 more servers mid-week. >> >> You will be wise to rebuild your databases on 9.x as you suggest. My >> experience with in-place migration has been nothing but nightmare after >> nightmare. My users are getting impatient and still finding new instances of >> the code incompatibilities discussed above. You will still need to do >> a lot of testing with your code no matter how you migrate. >> >> Happy upgrading... >> >> Jeff >> >> Axel Sander <axsander@okay.net> wrote: >> >> >Hi, >> > >> >we plan to upgrade our databases (1 to 3 GB) from 7.3x to 9.x (Solaris >> >2.6). I think, a clean installation would be better than converting my >> >existing databases. >> >Are there drawbacks to drop and rebuild my databases and just convert the >> >root dbspace to keep my disk layout (temp, log and phys dbs) or would it be >> >more effective to do an "oninit"? >> > >> >TIA >> > >> >Axel >> > >--------------244A9D8009CD708F23E2D2E7 >Content-Type: text/x-vcard; charset=us-ascii; > name="doug.mcallister.vcf" >Content-Transfer-Encoding: 7bit >Content-Description: Card for Doug McAllister >Content-Disposition: attachment; > filename="doug.mcallister.vcf" > >begin:vcard >n:McAllister;Doug >tel;work:(603) 791-5688 >x-mozilla-html:TRUE >url:www.fidelity.com >org:Fidelity Investments >version:2.1 >email;internet:doug.mcallister@fmr.com >title:Consulting DBA >adr;quoted-printable:;;2 Contra Way=0D=0AT1Q;Merrimack;NH;03054;USA >fn:Doug McAllister >end:vcard > >--------------244A9D8009CD708F23E2D2E7-- ------------------------------------------------------------ --== Sent via Deja.com http://www.deja.com/ ==-- Before you buy.