Re: Problem /w 7.1 and AIX

Catherine, This sounds like Bug # 42264. It is known in 7.10.UC3 on a Sequent. My notes indicate it is fixed in 7.10.UC4 (also on a Sequent). If a table has multiple extents on the same chunk an index build will produce a bad index. Multiple index values will point to the same row. This is for non-unique indexes. You won't be able to build a unique index on the table. The informix error was 371 and isam error 100. Conversely, if you load a table which already has the indexes on it and this table has multiple extents on the same chunk, running oncheck -ci will give you a FALSE error. Oncheck -ci builds a new index and compares it to the one that exists. Oncheck builds a *bad* index and thens says the *good* index on the table is bad. Export and importing the table usually solves the problem because the table ends up as a single extent or at least with no multiples on the same chunk. I had this problem in Oct 95. There is no excuse for Tech support not knowing of this, unless there are so many bugs they can only keep track of the last six months. :) If you need more info let me know. Regards, Steve Berg - spb@masada.nb.com On 4 Jun 1996, Catherine E Rigby wrote: > A client's site is running Informix 7.1 on AIX 3.2 (rs6000 570) and the server > has been running steadily for about 2 years now (prototyping several > applications). Anyways, recently while running an oncheck -ci to test index > intregrity it was reported that several tables had duplicate indexs which were > specified to be unique. A select from the tables reported that there were no > duplicates. We dbexport'ed the database and checked them for duplicates, but > none were still found. Informix technical support had never heard of this > problem, but did state that 7.1 on AIX did have its share of bugs. Not > knowning how far back the corruption went, we couldn't risk using an ontape > archive which could be corrupt. After having oncheck repair the indexes, we > ran it again. This time, index errors occured on different tables than > before. The only solution we had was to drop the database (a very tense and > scary moment i must add), and reimport it using the previous dbexport. All > has been fine since then...but has anyone every heard of this or know what > causes it? > > thanks in advance > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Catherine E. Rigby > *----- cer39571@pegasus.cc.ucf.edu -----* > Coffee: the milk of chess players and thinkers > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >