>I've got this table over at a client's office that's giving me fits. Every couple of days it seems it loses it's index. This table only has one index. The wierd thing is that the .cdx file is still there, but when you modi struct the table, there's no index to be seen.
>
>I highly doubt it's something caused by our code becuase that hasn't changed in several months and this is a relatively new problem. I'm going to confirm that tomorrow, but I really don't believe it's due to the code.
>
>This one table is accessed by other programs, from what I understand, so I'm thinking it's some other program that's causing the problems, but I don't even know where to begin to look. Especially with the wierdness of the .cdx still there but no index.
>
>If anyone could give me a clue as to where to begin looking, I'd greatly appreciate it.
>
>Denise Duggan
If the file is being accessed by an older program, say access, it is probably saving as a DBASEIII or other "pre-FOXPRO 2.x" format. i.e. Changing the byte, referred to by David. You need to find out who is accessing it and with what. If you are an a Novell network, you could possibly find the culprit by issuing a "NDIR yourtable.dbf" to see who last modified the file. If you cannot, I would add a statement to the main program to refresh the link. Something like...

USE yourtable
if empty(cdx())
USE yourtable INDEX yourtable.CDX EXCLU
* I would reindex to ensure that the indexes are up to date
* since you would not be sure if any record value had been changed
* since the link was lost
REINDEX
endif
USE