Corrupted tables SE-- How do I repair them

I'm running SE on SCO and have two corrupted tables from power failure. I've tried running secheck, and Repair Table with no luck. Both tell me I have duplicate unique indexes or duplicate records but do nothing to fix the problem. Can anyone point in a direction how to repair the tables. I'm thinking about importing the .dat files into Access to clean them up and run secheck for the index files. Help Randy

Randy wrote: > I'm running SE on SCO and have two corrupted tables from power failure. I've > tried running secheck, and Repair Table with no luck. Both tell me I have > duplicate unique indexes or duplicate records but do nothing to fix the > problem. Can anyone point in a direction how to repair the tables. I'm > thinking about importing the .dat files into Access to clean them up and run > secheck for the index files. One option is to try the isextract program from the IIUG archives. It unloads most forms of data from C-ISAM files, but won't work properly on temporal (DATE, DATETIME or INTERVAL) data, which are not officially part of C-ISAM anyway. One year... The other possibility is to try creating new tables (possibly in a new database) with the same data structure as the damaged ones. Then copy the index files from the new tables over the corrupted index files. Then run secheck. It will complain about missing records, but it will also rebuild the indexes. Of course, if the actual table data is corrupt, you need to clean it first. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

Thanks for the input but I couldn't wait. So I went on orginal idea. I did a dbexport and import the unl files for the corrupted tables into MS Access to found out which records were corrupted and deleted them from the unl file. Then I adjusted the db.sql file that dbexport creates to reflect the new record count for the table (since I delete records) Then last but not least I used dbimport to restore the database. What a pain. But it worked:-) "Jonathan Leffler" <jleffler@informix.com> wrote in message news:399080B8.35478DFB@informix.com... > Randy wrote: > > I'm running SE on SCO and have two corrupted tables from power failure. I've > > tried running secheck, and Repair Table with no luck. Both tell me I have > > duplicate unique indexes or duplicate records but do nothing to fix the > > problem. Can anyone point in a direction how to repair the tables. I'm > > thinking about importing the .dat files into Access to clean them up and run > > secheck for the index files. > > One option is to try the isextract program from the IIUG archives. It > unloads most forms of data from C-ISAM files, but won't work properly on > temporal (DATE, DATETIME or INTERVAL) data, which are not officially > part of C-ISAM anyway. One year... > > The other possibility is to try creating new tables (possibly in a new > database) with the same data structure as the damaged ones. Then copy > the index files from the new tables over the corrupted index files. > Then run secheck. It will complain about missing records, but it will > also rebuild the indexes. Of course, if the actual table data is > corrupt, you need to clean it first. > > -- > Yours, > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > "I don't suffer from insanity; I enjoy every minute of it!"

1/ delete corrupted .idx files and recreate them. (copy from .ifx initials) 2/ run secheck Good luck Randy <srsolution@home.com> a 'crit dans le message : X9Tj5.10031$65.98382@news1.rdc1.fl.home.com... > I'm running SE on SCO and have two corrupted tables from power failure. I've > tried running secheck, and Repair Table with no luck. Both tell me I have > duplicate unique indexes or duplicate records but do nothing to fix the > problem. Can anyone point in a direction how to repair the tables. I'm > thinking about importing the .dat files into Access to clean them up and run > secheck for the index files. > > Help > > Randy > > >

And what clown said that MS Access was good for nothing? :-) Cheers-- Charles Randy <srsolution@home.com> wrote in article <Er4k5.10615$65.103585@news1.rdc1.fl.home.com>... > Thanks for the input but I couldn't wait. So I went on orginal idea. I did a > dbexport and import the unl files for the corrupted tables into MS Access to > found out which records were corrupted and deleted them from the unl file. > Then I adjusted the db.sql file that dbexport creates to reflect the new > record count for the table (since I delete records) > Then last but not least I used dbimport to restore the database. > What a pain. But it worked:-) > > > > > > "Jonathan Leffler" <jleffler@informix.com> wrote in message > news:399080B8.35478DFB@informix.com... > > Randy wrote: > > > I'm running SE on SCO and have two corrupted tables from power failure. > I've > > > tried running secheck, and Repair Table with no luck. Both tell me I > have > > > duplicate unique indexes or duplicate records but do nothing to fix the > > > problem. Can anyone point in a direction how to repair the tables. I'm > > > thinking about importing the .dat files into Access to clean them up and > run > > > secheck for the index files. > > > > One option is to try the isextract program from the IIUG archives. It > > unloads most forms of data from C-ISAM files, but won't work properly on > > temporal (DATE, DATETIME or INTERVAL) data, which are not officially > > part of C-ISAM anyway. One year... > > > > The other possibility is to try creating new tables (possibly in a new > > database) with the same data structure as the damaged ones. Then copy > > the index files from the new tables over the corrupted index files. > > Then run secheck. It will complain about missing records, but it will > > also rebuild the indexes. Of course, if the actual table data is > > corrupt, you need to clean it first. > > > > -- > > Yours, > > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> > > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > > "I don't suffer from insanity; I enjoy every minute of it!" > > >

Sometimes I find that 'bcheck -k' will fix the problem. It renames the .idx file to .IDX and then builds a new .idx. I did this to all the system catalogue indexes on one system and it was interesting that: 1) Some of the .idx sizes were very different to the .IDX sizes and 2) The users reported that the machine was much faster! However secheck/bcheck won't fix duplicate data records. You will have to find & fix them yourself by one means or another. On Tue, 8 Aug 2000 13:37:11 +0100 , "Randy" <srsolution@home.com> wrote: >I'm running SE on SCO and have two corrupted tables from power failure. I've >tried running secheck, and Repair Table with no luck. Both tell me I have >duplicate unique indexes or duplicate records but do nothing to fix the >problem. Can anyone point in a direction how to repair the tables. I'm >thinking about importing the .dat files into Access to clean them up and run >secheck for the index files. > >Help > >Randy > >