Re: Severe database corruption
Opportunistic lock (OL)
OL is a -BIG- source of corruptions: deactivate OL -ALWAYS- for work with
"x" <email@example.com> escribió en el mensaje
> From Ads forum, a very old message says:
> 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
> 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,
> 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
> 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
> 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
> client application would not result in corrupt data. If Advantage
> 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
> Probably none of this is new/useful. However if you can send an example
> table with to us (firstname.lastname@example.org), we can possibly determine what
> might have happened. Error logs from the time of the problem would also
> extremely useful.
> Mark Wilkins
> Advantage R&D
> "Corinna" <email@example.com> wrote in message
>>I would like to know what the various causes of table corruption (not
>>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
>> 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
>> working fine?
>> Mostly what we've seen is hosed date fields, and random characters in
> "Tito" <firstname.lastname@example.org> escribió en el mensaje
>> From a couple of years and i'v been having the same issue when it was
>> a novell netware, and now it's on a Ubuntu server, I have a DBF file
>> that gests corrupted, arroud record 100 to record 200 usualy it loses
>> 1 byte, tryed change computer, network cable, server, workstation,
>> windows from 98 to Vista, and hapens in every situacion or OS. So I
>> have no clue what might be happening, or how to prevent that.
>> Any clues?
>> I use clipper 5.01