>>>>>I have an application that does the following:
>>>>>
>>>>>1. Looks for the existence of a cdx file to a table (in this case, called aging.cdx. The table name is aging.dbf)
>>>>>
>>>>>2. If the cdx file exists, delete the cdx becuase I want to rebuild the index later in the code.
>>>>>
>>>>>3. open up the table, write data to the table and rebuild the index.
>>>>>
>>>>>4. Once all steps are complete, print report and continue with the next record to be processed.
>>>>>
>>>>>5. The problem is, on all subsequent loops, it gives me the structual cdx not found everytime i try to open the table up without the cdx.
>>>>>
>>>>>Any ideas? or better ways to handle getting a clean index on a table.
>>>>

>>>>lparameter fajl
>>>>cdx=forceext(fajl,'cdx')
>>>>on error
>>>>m.xx=fopen(defaultext(fajl,'dbf'),12)
>>>>if m.xx>0
>>>>        =fseek(m.xx,28),fwrite(m.xx,chr(0)),fclose(m.xx)
>>>>endif
>>>>
>>>>if file(cdx)
>>>>        erase (cdx)
>>>>endif
>>>>

>>>>Just pass it the table name and this will remove the "this table has a structural index" byte in the header, and then erase the cdx. After that, your table has no structural index and does not ask for one. Any referential integrity which may rely on existence of any of these indexes will get marooned - but I figure you've handled that already, or have no such concerns.
>>>
>>>Gee, drastic !
>>>Now give us poor fellows the other way around.
>>>I mean, after the INDEX ON it's always nice to have the structural index back, right ?
>>>
>>>< g >
>>
>>Hey, that's a different question. This was about killing an index and having the table stop complaining about it.
>>
>>Resurrection via Index On is a different, and trivial, matter. Just do it, and it will come into existence.
>
>Well, I thought the procdure was a bit beyond that. But never mind, you win.
>However, I'd say that the process is a bit unbalanced now. Like needing to create a document in Notepad in order to look at it from Word.
>Or IOW, the whole thing should be solved by never having a structural index again after removing it. Or better, never have it in.
>You win in advance.

Well, the originator of this thread had his reasons for doing it this way. It was probably much faster to append a ton of records into a table without an index, and index later, than to append with indexes present and have Fox update indexes on the fly.

The code I posted is an excerpt from my indexing routine generator. It was written in FPD days, where lots of users had problems with bad network cabling or unstable power supply, so the indexing routine couldn't rely on the table being intact, nor on the index being intact. So it made no assumption on the state of the .cdx file - it just killed it and made a new one, just in case. This was much safer and more reliable then to try to open the table first, and then check for errors. Sometimes an error in the .cdx file header may have hosed the whole machine (DOS days...), so this was the sure-fire way to end up with good indexes. The routine also checked the health of the table itself and its memos, and automatically fired up the table rebuilder. Had to think hard about those things back then.