New records all scrambled!

[RoadRunnerOz]

My client just lost 30 new records!
Every new record added was scrambled when his laptop locked up and my client had to reboot.
All existing records changed were ok for some reason??? My client had been adding records over a 2 hour period.

Details
All tables are opened when the app starts. None are opened in the DE.
I use row buffering on all tables.
Ex: =CursorSetProp("buffering",3,"company&quot
This is how I saved records:
if !Tableupdate(.T.,.T.,"company&quot
message...
return

This was a stand aloneapp on a win95 notebook ( about 5 - 7 years old, 500 meg HD, 64 meg ram)
There are no begin transaction ... commands
The app is written as multi user for the future but only one person uses it at a time.
There are two tables: employee and tests. 30 tests were added for existing employees and 6 new employees were added with 6 tests. (36 tests added)
When a record is added to the test table data is also written to the employee table.

What happened: The PC locked up after 2 hours of adding records. After reboot, all the new tests were scrambled, the 6 new employees remained but were also scrambled. The "funny" part: The 30 existing employee records all had the correct updated information.

The program is very slo

http://www on

that particular laptop and the user is impatient. It may not have locked at all but that's the explanation I got.

Any helpful suggestions out there?
Michael Ouellette
mouellette@compuserve.com

 

[rgbean]

Michael,
Win95 uses a standard DOS based FAT file system, and as such it is not very reliable when "crashed" - especially if the harddisk itself caused the crash. Laptops are particularly suceptable because of the power saving techniques they use. The new records may have been written on a part of the disk that is marignally good, where the updated records obviously have been previously in use.

You may want to ask your user when was the last time he ran a SCANDISK and/or DEFRAG - these would exercise and verify the disk outside of your application. On a system this old, a run through a set of diagnostic routines might not hurt and could show up a "weak" power supply, "flaky" memory or "soft" spots on the harddisk.

Rick

 

[craigsboyd]

sounds like some kind of data flush to disk that went horribly wrong...i only say this because the existing records were fine and the new ones were all garbled...only other thing that I can think of is that the area where the new records were written to has been scrambled or the FAT got messed up as Rick eluded to and the old records were written in other parts of the FAT or the disk that escaped unscathed. I've seen this horrible scramble stuff but not since the days of Fox 2.6, I think it is a testament to the dbf format and FP that the tables are even able to be opened and read through that type of damage. Slighthaze = NULL

 

[RoadRunnerOz]

Thanks Michael Ouellette
mouellette@compuserve.com