>No I work extensively in house, nobody else has access the the code.
Well, the question then is: Do you have set exclusive off in your IDE? And do you work on separate development and test data?
The only regular CDX corruptions I had was definitely with oplocks and way back then the simplest solution was Windows Server 2003, that wasn't the newest Server OS back then, but it wasn't far after 2003 when this was quite a new thing.
And the files there weren't empty (or just header size), the index tags just had errors very often apparent from SEEKs and Rushmore optimized queries and then REINDEXINg helps, but only is of short term help.
It was fortunately in a system only used by a few select users in that company, but of course, also the more important users, having to do with the final decisions of whether a developed product would go to the market.
Anyway, CDX corruptions, yes, but in that form, I can only imagine that to happen by operations doing index rebuilding, which includes all the things I already mentioned from REINDEX over PACK and ZAP and the only thing else would be ALTER TABLE. Besides exclusive access necessary to make a similar alteration, but then the question would be why?
I still strongly suspect antivirus freezing that state of the file as it is an alarming thing if a file is truncated like that and begins to rewrite. And there is client side and server side antivirus and intrusion detection software and software and hardware firewalls.
Only when rebuilding a CDX you go through the stage the CDX is just its header. The first thing written out to a new file is the header information. As that's what you see as files, I can only imagine that it comes from inside of the VFP IDE or some action of your application or helper tools you wrote. That doesn't happen randomly, that doesn't happen as network error regarding a block of the file or as file corruptions in the index tree structures. That happens when the CDX files are rebuilt. Why should the CDX be like that for any other random reason?
I mean, you could take such a corrupted file and compare it to the file you get when you ZAP a healthy version of the table. Is it really exactly like you describe, are the CDXes exactly that header part or are they perhaps the first file block? There will be a difference, even though much of VFPs file structure has sizes equal to the file block sizes of that era, a CDX header has a varying size, not necessarily in multiples of 512 bytes (Windows Explorer makes the distinction of logical file size and file size on disc in blocks, as you know and CDXes usually have a logical file size not in multiple of hdd file system blocks).
At several times I also suggested backing up the CDX files in that empty state is a good way of healing indexes aside from a clean solution to delete all tags and rebuild them with VFP code. But putting back CDX in this empty state alone isn't healing corrupt CDXes, obviously. It's only the first step before a REINDEX then can take that CDX information and the still healthy DBF and FPT to recreate the full CDX with all it's index tag trees.
So if anybody in your company did that and took it from my recommendation, please forgive me, but then they didn't understand me very well. It is a way to make good use of REINDEX, as REINDEX only fails on corrupt CDX headers and that's why several experts recommend to never use the REINDEX command, you can use it with a healthy CDX header and you can be sure a fresh CDX is healthy. So if you make backups at the point a table was new and empty (or small) you have the bare minimum healthy file piece you need to recreate the whole bunch of indexes with REINDEX. It's still an operation you can only do with exclusive access, even though the process only needs write access to the CDX file, its the way VFP choose to limit such operations. So it's still not a repair option on the fly and during the course of the day.
Which reminds me of a last thing worth mentioning: I had a mechanism in place to end an application by administrative needs to do so, a timer listening for a sign to sign off. And that wasn't a sudden quitting of the apps nor shutting down the server and letting everybody crash, it started off with informing any user the system will go down for maintenance and they have 5 minutes to save important changes and exit themselves or get shut off after that grace period. With repeated alert every minute. Obviously in a nonmodal way, as the message box was extended with the timeout parameter that was very welcome as it would still appear in its modal state overriding any other action a user did and being noticed, still ending itself to allow the timer to become active again and finally shut down the app. It's helpful to have such a mechanism for the on-site administrative personnel.
Bye, Olaf.
Olaf Doschke Software Engineering
