We came across this a few years back when moving and copying files at the OS level (usually copying the data file but not the associated index).
What's even easier than creating a dummy index (especially on a large file) is to simply copy another files index (X_smallfilename) to your working file (X_STUMAST). Then you can do the DELETE.INDEX STUMAST ALL. hth Colin Alfke Calgary, Canada -----Original Message----- From: regalit...@aol.com This information has been extremely helpful! I had 11 files have the indexes go bad on them, and they needed to be completely rebuilt. The only anomaly is that the "DELETE.INDEX fn ALL" didn't work right away. There was an index on the file, a V-field, called "XERP.SQLTRIG". When the index went bad, it was there, but not really there. On a file called STUMAST for example, I would say: :LIST.INDEX STUMAST No indices created on file "STUMAST" : Then I would say try to create the index: :CREATE.INDEX STUMAST XERP.SQLTRIG "XERP.SQLTRIG": can not create multiple indices on same location No new indices are created : So UniData sort of knows the index was there, but it doesn't really know. And unfortunately, that is my problem. I tried to delete it: DELETE.INDEX STUMAST ALL No indices created on file "STUMAST" : And the create index would fail again. So what I did was create another index, I actually indexed @ID, then the "DELETE.INDEX STUMAST ALL" did work, and I was able to re-install my original XERP.SQLTRIG index. So, basically, by creating (I did not actually have to build) a bogus index and then doing the "DELETE.INDEX fn ALL" it did solve my problem. Is this a UniData bug or two that might be looked into by any chance? :-) (I saw my issue on UniData 7.2.2 for Windows) Thanks! Steve... _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
