How to Validate UniVerse Index files

Is this UniVerse or UniData ?

On UniData you can use guide_ndx at level 3 to check both the physical and logical integrity of an index.

Do you have an example of the dictionary field used for the index?

Is it a simple field descriptor or is it a calculated field? 

Sorry missed the subject line where it mentioned UniVerse

Ok. I was thinking it could be a virtual field which referenced some other file such as a TRANS. That is not recommended for an index.

I'm not aware of any issues currently with an index on a simple data field. One thing which comes to mind is it possible that 2 different data files are pointing to the same index file? This can happen if a file with indexes is copied at the OS level and the index path in the header is not removed. In this case, updates to 2 different data files would be updating the same index and this most certainly cause the index to get out of sync.

From what you said it sounds as though it is the logical integrity of the index data and not the physical integrity that is the problem. I don't know of anything that scans for that as it has to compare with the original file. Unlike UniData, you can create an F pointer to a UniVerse index (not recommended by the way) and iterate through it like a regular file looking for any anomalies, but that's about it.

Have you moved/restored the file recently?  Maybe relocated an entire drive or directory?  Have you checked SET.INDEX CUSTOMER to see how the index is being managed in the file header?  We've found that it's almost always best to set the index to RELATIVE.PATH in order to avoid unexpected problems when paths change.

I will check if the file has been moved/restored and thanks for the relative pathing idea too.

Gil,

Please also check if it has been copied to or from elsewhere. If the index path is not set to RELATIVE then any updates to the copied file are likely to still be updating the index of the original file - see SET.INDEX. Unfortunately to check for sure you would need to run SET.INDEX on all likely files and look for a result with the (wrong) index path concerned. For the sake of proof, you could always move the file, dictionary and index to another file path such as a sub-folder  (don't foget to edit the VOC entry anmd use SET.INDEX). If there ar eother copies of the file elsewhere using the original index path then these will now fail and can be identified. 

The usual reason this comes up is because a copy of an account or a file has been taken for test or development purposes without running SET.INDEX. Using the RELATIVE option in all indexes current and future should fix this hole once and for all.

Regards

JJ

I use "blook" with -vn options to verify the state of an index on *nix systems.  Rocket advises, however, that this is reserved for Engineering and Support use

https://docs.rocketsoftware.com/bundle/see1687888467033/page/swp1687888077374.html