Re: re-creating .idx file

Two years ago I ran into this situation when a backup saved all of the .dat files and none of the .idx files. I called Informix and asked them what to do. They said, "Let us know how you do it, Have a nice day". :-( SO...I created a duplicate database (with .idx) and copied the .idx files with the new numbers associated with the .dat files. Just as Billy Wheeler stated below. But the SELECTs did not return all of the rows (even after bchecking) in the table. I had to INSERT into the tables dummy records until all of the "holes" in the file were filled. The end of file pointer is screwed up when the new .idx file is accessed. The pointer thinks the first hole (a deleted row in the table) is the end of the file. When the dummy record is inserted into the table the EOF file pointer drops to the next vacant row. So you have to fill up the table. Next you can either unload the table where the rows aren't dummy records or just delete the dummy rows and run a bcheck -ys. Hope this helps. Sorry It's a little late, Larry Hibbs lhibb@dillon.com > billy@west.co.za ("Billy Wheeler") wrote in article <5a153n$cfn@cssun.mathcs.emory.edu>... > On 27 Dec 96 at 16:06, Kevin P. wrote: > > oops! i hammered an .idx file while trying to "fix" an indexing > > problem with one of the tables in my system. yes, i know that it > > says practically everywhere in the manuals not to do this, but i > > figured if it was hosed already, what could it hurt. so, while i sit > > here listening to my multiple tape backup set whir, i figured i'd > > also ask the experts. > The experts are all on leave, so you'll have to make do with me... > Right: > 1. Create a table (newtable)which is an exact duplicate of your > damaged table (badtable), including all indexes. > 2. Copy the newtable_xxx.idx to badtable_xxx.idx. > 3. bcheck -y badtable*.dat