RE: 7.01 upgrade

Jason - Contact Informix Support, and Tell them what you are seeing. I found the same problem. Reference Bug #40338. I ran into this on UD1. The bug description doesn't match 243/113 errors we were seeing when attempting to build index, but Advance Support guys were able identify the match. The problem has to due when building indexes on tables that have (as an example) the initial extent on chunk1, the second extent on chunk2, a third or more extent(s) on chunk1. When initiating the scan threads, they end up with 2 scan threads on chunk1, which generates duplicates for the index, which are not sorted out during the merge. Informix has a fix available....just pressure them. Jon Vemo ---------- From: Radio Spares[SMTP:rswa@perth.DIALix.oz.au] Sent: Sunday, September 24, 1995 8:28 PM To: informix-list@rmy.emory.edu Subject: 7.01 upgrade Dear All, I had an aborted attempt at upgrading from informix 5 to informix 7.1. Below is what happened. If anyone knows anything about this I would appreciate the information. Also is anyone running 7.01.UC1 on Solaris 2.4? 1. Upgraded the O/S from Solaris 2.3 --> Solaris 2.4 2. The following patches were installed: 101945-04, 101981-01, 102007-01, 101977-01, 102011-02 3. Set all the kernel parameters per the machine notes. 4. Then copied the new version of 7.01.UC1 and ran the install script. 5. Set the parameters to the values we had been using on our test machine with a few changes to allow more user threads and locks etc. 6. We initialised informix and it came on line OK. 7. During our testing we had a problem with large indexes not converting to the new format with update statistics or oncheck -cI. These indexes had to be dropped and re-created. So we had a script ready that would go through all indexes and drop and create them. We ran this script. 8. The SQL script bombed out on 15 of the indexes. The error was -371 Cannot create unique index on column with duplicate data. 9. We created the indexes without the unique clause to have a look at the data. We found that when selecting data from the table using dbaccess there were varying numbers of duplicate records. Some records were not duplicated and others had up to 8 duplicates. We did an unload of the table and found that in the unload file there were no duplicates, the duplicates only appeared when selecting data from dbaccess. We dropped and re-created the indexes several times but this did not correct the problem. 10. One of the tables was unloaded, dropped and recreated and loaded again. This fixed the problem for that table. 11. At this point we stopped the upgrade and restored our backups. TIA Jason Harris (RSWA)