FiveTech Support Forums

Antonio Linares wrote:If indexes are fine, then the technical reason that comes to my mind is that the writting of a record may fail randomly (and this could happen from the DBF engine itself, its a possibility).

A failed operation can corrupt the DBF or write garbage to the current record but can't delete the record and recompact the table.

EMG

Enrico,

If a buffered chunk of data is written and part of it gets corrupted, that could do it

A log file (what I named a "backup" dbf) could reveal if the operation was done but the record vanished (?). I am just guessing, trying to imagine what may be going on...

As Enrico, Antonio, and I have said, it is not possible for records to disappear from the middle of a DBF (unless a PACK or COPY TO has been done).

The only ways for records to seem to disappear is for the record to never have actually been written to the file (I have never had this happen), or for the original record to be overwritten by another record.

For troubleshooting (as Antonio suggested), you could create another DBF file and write the recno(), ID, date, and time every time a record is saved to the original DBF. Then you could later track exactly what happened.

Regards,
James

Antonio Linares wrote:Enrico,

If a buffered chunk of data is written and part of it gets corrupted, that could do it

Then you would get a corrupted record not a vanished record.

EMG

Enrico,

Yes, I think you are right about it

Antonio,

Wouldn't your suggestion (using a backup DBF) not slow down the application enormously? In my application a few thousand new records are written every day. Some DBF-files have moren than 1.000.000 records.

Thanks.

Michel,

Wouldn't your suggestion (using a backup DBF) not slow down the application enormously?

I don't think he meant to create a backup of the entire database each time it was updated (if that is what you were thinking).

I think he just meant to add records to two identical databases. If it took 1 second to save to the original file, then it would only take 2 seconds to save to two files. This is not something that users would probably even notice. My concern with this is that if it is a coding issue that is causing the problem, then both databases would be identical and you learn nothing from them. If it is a corrupted index causing the problem then this would not affect both databases at the same time so you would see a problem.

However, as I suggested, you could just create a tracking dbf that only records four fields and this would probably be much faster. Regardless of coding or index problems this gives you a record of all changes to the original DBF.

James

driessen,

I have some DBFs with 10 million records, without problems.

regards

Michel,

Is the only solution that I can think about (by now) to debug it. Maybe you could code it to set it on and off if required.

If a record disapears, then we need to have a concrete situation, some initial info and a way to reproduce it so if there is a problem, it could be reproduced, reported and solved

As James explained, I don't think it will impact the overall performance of the app very much.

FYI - The problem of orphan child records can be solved using .Adt tables with a primary index key and simple Referential Integrity rules on the data dictionary. ...and it works with the local (free) version of the server just as well.

One other thing: In the old days, before I used the ADS server, I used to keep all tables closed at all times. If you need to update, insert, or delete a record, the application would open the table, do its thing, and then close it right away. That keeps corruption at bay and if you are only working with 5 or less users, it hardly hurts performance.

Hope that helps,

Reinaldo.

I confirm it was the antivirus.

Moving to Eset Nod 32 solved the problem.

Thanks for your feedback and very interesing advice.

I set antivirus proograms to ignore DBF and NTX files. In addition to other problems you don't want the antivirus software to scan DBF's and NTX's every time a record is saved.

Regards,
James