>From Advantage: >>>>>>>>>>>>>>> Hi Corinna, I probably don't have anything to mention that you have not thought about. In addition to what John mentioned, some potential issues that I can think of include the following:
Bad hard drive (or possibly a bad hard drive controller): This could result in bad data being written or read incorrectly. This type of thing could lead to "random" characters appearing in fields. This type of problem can generally be detected by running various disk utilities. Bad memory: This normally would result in all kinds of flaky computer behavior but could potentially hide itself and result in garbage being written to a table. I don't think bad memory is a very common problem, but we have experienced it in some of our test system computers on a few rare occasions. Again, this can be checked pretty easily with system utilities. Power outage: This could possibly result in data not being written to the disk. In general, I would normally expect this to be a problem only with indexes not being updated correctly. It does not seem likely to me that random data could end up in a record because of a power outage (at least I am not aware of any situations like this). The record simply would not be written normally. Sometimes it is possible for an appended record to be blank due to a power outage (the file is physically grown for the new record but the actual record never gets written), but this would normally have zeros (probably appear as NULLs). Crashed application: I would think this normally would have results much like a power outage; the data simply would not get written. With an Advantage Local Server application, any client crash (or turned-off computer) can result in problems. With Advantage Database Server, a crashed client application would not result in corrupt data. If Advantage crashes, however, it could result in data not being written (and we would want to know about any of these cases). Memory overwrites: And finally there is the "bugs in the code" case. Any bugs in Advantage that would result in corrupt data are obviously a high priority item for us to fix. But it is possible for bugs in a client application to result in garbage data. A memory overwrite in the client application could trash the record buffer before it is sent to the server. The record could end up on disk with whatever data was in it from the client. Probably none of this is new/useful. However if you can send an example table with to us ([email protected]), we can possibly determine what might have happened. Error logs from the time of the problem would also be extremely useful. Mark Wilkins Advantage R&D "Corinna" <[email protected]> wrote in message news:[email protected]... >I would like to know what the various causes of table corruption (not index >corruption) are. I have a customer who has experienced corruption in a >couple of tables over the last few months. Are there KB articles about >this? I didn't have much luck searching. > > I know one cause is a power outage-- that happened once to them, then they > got a UPS. Is it possible for the UPS to not deliver enough voltage (or > whatever), and cause data corruption even if it appears that the server is > working fine? > > Mostly what we've seen is hosed date fields, and random characters in char > fields. > > -Corinna >>>>>>>>>>>>>>> Regards Antonio Martinez escribió en mensaje ... >Hi to all, > >a question: > >Why a .dbf table goes to corrupted ? > >Perhaps, break energy ? >Perhaps, shutdown computer (user) ? >Perhaps, Clipper and Harbour using the same dbf tables ? >Perhaps, Windows protocols (SMB) against system file based ? >Perhaps, ....? > > > >Regards > > > > _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
