Charles,
The only explanation that we think could have accounted for this is that a user
had restored a file, using uvrestore. When they restored the file, they
restored it under another file name. As we all know the index location is
stored in the header of the file. When we run our resize
Every problem I have seen here was caused by running index operations while
a file was in use.
Golden rules:
1. Make sure no-one is using the file
2. REALLY make sure no-one is using the file
3. REALLY, REALLY make sure (you get the idea).
fuser -u name of Unix file name
This is your friend
Could be that RESIZE isn't re-creating the index pathname in the file's header
- which, if true, would be a bug.
A workaround would be to follow the RESIZE with a SET.INDEX command to
re-inform the hashed file about the location of its indexes.
---
u2-users mailing list
I have seen where the system automatically creates a new index when it
encounters an error. I have two sets of indices right now on my system.
We didn't create them so the system must have.
I_CUST.HIST.XR00
I_CUST.HIST.XREF
I_CUST.MS00
I_CUST.MSTR
I've checked the SET.INDEX and the 00 files are
