In trying to see what could be wrong I analyzed the a_vtas.dbf you attached and I see no general file corruption or index corruption in it.
I see a lot of inconsistencies, just picking out some examples:
Fetchor datetime values are sometimes the empty date, always in conjunction with Granor being "si". In all other case the datetime values stored have no time portion aka are dates at midnight as time. You could also use a date field for that.
The field v_tarj char(2) is space(2) in most records, some are 'si', some 'no'.
The Vend field sometimes is all upper case, sometimes not.
The list can be extended, but nothing of that is file corruption or data errors, I would say that's inconsistent data, but without knowing the whole system I can't tell you whether you should do something about the data or not. I can't explain a 70 in n_vta, because no record has that value and there are no deleted records in that dbf. So I also can't confirm our last sensible explanation of that value coming from a deleted record. I can assure you VFP does not invent values that are not in the data, for values not in a DBF an SQL query would need an expression calculating a value, but there is nothing like that in the query you posted or in the queries I see in some button click events, that would play a role.
So the only sensible remaining explanation is you have queried another DBF file, not the attached one. Blaming it on a faulty Windows installation is very questionable, blaming it on file corruption. Well, I can't see that in the file you attached.
The CDX also is fine, not only as it is a CDX and not an IDX, but I also don't find any corruptions within that CDX. Only the fec_vta field is indexed at all and all records are in the index, which can be seen from comparing a count to nTotal with reccount.
What strikes me as strange is that the fec_vta field only has the values 07/20/2023, 07/30/2023 or 07/31/2023, which seems to me to only be an extract of the data within the date range you wrote as the range you queried. That lets me think it could be data queried INTO TABLE somewhere in your application, and tables generated as files are something I personally avoid as for temporary results we have cursors, if you need extracts as dbf file because reports are fed by that, well, file generation can sometimes go wrong, especially if the hard drive isn't healthy, but then you might have overwritten a corrupt a_vtas.dbf with a DBF that's no correct.
If such files are generated and overwritten it would also explain why you sometimes see values and sometimes not, it would depend on what extract is taken out from yet another central table that's the source of generating temporary a_vtas.dbf, but all that is just guesswork again, based on the fact that the fec_vta value are exactly within the data range you queried.
The buttons in your two CXes, don't have INTO TABLE queries, though, that could only be somewhere else in your whole project.
If you then don't take a snapshot, simpler said a backup or copies of the files as they were exactly at the time you had a problem, then there's also no chance to examine that and see what is wrong with them.
All that also is based on the assumption, this system exists for longer and for more than the 3 dates in the data. Maybe you store data in separate DBFs per month, I don't know, as long as you don't tell more about the system. Then it becomes very likely again, that you get values you don't expect simply because the current directory points to a directory of another month, then you should get no data querying for dates definitely only from July. But who knows how the data is organized in your database.
I can only warn about creating DBFs in a DBC that's used shared. I know the DBF comes from a DBC, as first opening it pointed out the DBC is missing, which gives the option to make it a free table. If you add tables to a DBC very frequently, that can be a root cause of file corruptions, because a DBC also is only a free table and generating tables means inserting new records, altering a table updating records, etc. Like any DBF, also these changes can cause corruption, but then it's a more serious corruption than that of data, the structural informations about the dbf get wrong. Ideally, a dbc is only really changd by the developer and then the production database is upgraded with exclusive access without users using the application.
Then you only read the DBC data when your end users use it shared, and reading files has no potential to cause corruptions, file corruptions always and only occur when a file is changed and written to. ou obviously can't prevent that for DBFs of your database, but if you depend on generated DBFs, you better only generate free DBFs and keep them out of the DBC.
Chriss
