Severe database corruption

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

To the best of my recollection the stable release of 5.01 was 5.01a
(at least in US). Is there a reason you have not moved to 5.2e?

How does the corruption manifest itself? How often does it happen?
How big is the DBF?

What exactly do you mean by "loses 1 byte"?



================================================== =======================
On Feb 8, 10:40*am, Tito <clix...@gmail.com> wrote:
> 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

On Feb 8, 8:40*am, Tito <clix...@gmail.com> wrote:
> 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,
....
> I use clipper 5.01

Hopefully, you have patched yours up to current:
http://www.the-oasis.net/ftpmaster.p...ent=ftp_ca.htm

You could try putting in and keeping 200 blank records...

David A. Smith

Weel never changed my release because I have a library to print
Barcodes, and some others, and I thought that wouldn't function
correctly, so never tried, but if there is no problem and I don't have
to change code, has if we move for ex. to Harbour, I can trie.. where
can I find the latest release?

Regardind the The database, is a database that goes to 0 records on
the beguing of the month, and grows with invoice lines, it's
relatively small, in fields, but can corrupt any where in time,
independently of the number of records. When it gets currupted, i
fetch a copy, copy the first n records (where the corruption ends on
the live file) to another file then i append to the copied records the
correct records of the live file (all that with mfoxplus), when I
compere the too in fisical size most of the times have one byte of
diferençe..

The corruption is the change to ramdom caracters, some time it sems
like pices os other files, has if the operating system changed some
alocation in the disk, de odd thing is that most of the times only
this one gets corrupted..

On 8 Fev, 19:10, "E. Fridman" <pm771...@gmail.com> wrote:
> To the best of my recollection the stable release of 5.01 was 5.01a
> (at least in US). *Is there a reason you have not moved to 5.2e?
>
> How does the corruption manifest itself? *How often does it happen?
> How big is the DBF?
>
> What exactly do you mean by "loses 1 byte"?
>
> ================================================== =======================
> On Feb 8, 10:40*am, Tito <clix...@gmail.com> wrote:
>
>
>
>
>
>
>
> > 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

Tito,

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 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 (advantage@ianywhere.com), 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" <corinna@vestanotes.com> wrote in message
news:4586c010@solutions.advantagedatabase.com...
>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









"Tito" <clixfun@gmail.com> escribió en el mensaje
news:607f7afe-1dcc-4f67-8ce7-d59ed39a28d5@c20g2000vbb.googlegroups.com...
> 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

On Wed, 8 Feb 2012 07:40:12 -0800 (PST), Tito <clixfun@gmail.com>
wrote:

>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

Many years ago we had an application which used direct record
addressing and thus the database files had no indexes. One of the
small files regularly corrupted. We added an index to it and even
though we didn't use the index it was always opened with the data file
and the corruption went away.


--
AnthonyL

Tito,

More, about power stability, from José Alfonso Suárez, in Spanish ;-(

*********************
Hola,

Ante la gran cantidad de mensajes que veo con problemas en redes locales,
aqui os dejo unos consejos para que las redes os funciones bien.

La mayoría de las veces no se presta atención al cableado y es el pilar
centrar de toda instalación de red, un cableado defectuoso es causa de
graves problemas en la red: lentitud de la red, errores en las aplicaciones,
corrupción de indices, etc.

En el mercado existen varios sistemas para comprobar que el cableado de la
red es correcto, desde software hasta aparatos electrónicos. Lo malo de
estas herramientas es el precio. Tambien existen empresas que se dedican a
la instalacion de redes y hacen certificaciones del cableado usando estos
aparatos.

La instalacion del cableado debe de contemplar unas minimas normas:

- Cables, rosetas de pared y terminales RJ45 compatible con la categoría 5
(para redes de 10 Mbs) o categoría 5 mejorada (para redes de 100 Mbs).
- Cables de red alejados de los cables de electricidad.
- Los cables no deben formar curvas que puedan producir la rotura del cable.
Las curvas deben ser suaves.
- Los cables no deben estar aprisionados. Si se sujetan con abrazaderas de
plático, no deben apretarse mucho, se corre el riesgo de cortar un
cablecillo.
- El trenzado final de los pares, en las rosetas de pared, no debe
deshacerse. (El trenzado es para evitar los ruidos radio-electricos y
electro-estaticos).
- Los terminales RJ45 de los latiguillos de conexión deben estar
correctamente crimpados.
- El código de colores correcto en los RJ45 es:
blanco-naranja/naranja blanco-verde/azul blanco-azul/verde
blanco-marron/marron
(observad que se cruzan los pares centrales)
- Las rosetas de pared llevan dos tipos de conexionado, el correcto es el
que va cada par combinado. Recordad que no se pueden destrenzar los cables
para conectarlos a la roseta, se produce ruido.
- Los cables no deberan estar por el suelo, evitando en medida de lo posible
que sean pisados.
- Los cables no deberan estar tensos.

Como veis el cableado es primordial, si el cableado es defectuoso podeis
usar el mejor software, las mejores tarjetas de red, los mejores switches,
los mejores hubs, etc., que la red siempre dara problemas.

Si alguien quiere más información sobre estos temas me puede contactar por
privado a jasm@oem.es.

Saludos,

Jose A. Suárez
Olivares 2000
















*********************

Regards

Tito,

And third:

Opportunistic lock (OL)

OL is a -BIG- source of corruptions: deactivate OL -ALWAYS- for work with
..dbf files.

Regards


"x" <alcisoft@arrakis.es> escribió en el mensaje
news:jh08p8$tqh$1@speranza.aioe.org...
> Tito,
>
> 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
> 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 (advantage@ianywhere.com), 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" <corinna@vestanotes.com> wrote in message
> news:4586c010@solutions.advantagedatabase.com...
>>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
>
>
>
>
>
>
>
>
>
> "Tito" <clixfun@gmail.com> escribió en el mensaje
> news:607f7afe-1dcc-4f67-8ce7-d59ed39a28d5@c20g2000vbb.googlegroups.com...
>> 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
>
>

> Bad hard drive (or possibly a bad hard drive controller)

> Bad memory

> Power outage

> Crashed application

> Memory overwrites

> And finally there is the "bugs in the code" case

And in addition to that: Bad network cards and/or drivers

Regards,
Klas

Ola Jose

Si tambien supus esse problema por esso conecte um cable directo desde
el ordenador al swich (con gestion..) e pssou lo mismo por esse no
eres los cables..

On 9 Fev, 12:15, "x" <alcis...@arrakis.es> wrote:
> Tito,
>
> More, about power stability, from José Alfonso Suárez, in Spanish ;-(
>
> *********************
> Hola,
>
> Ante la gran cantidad de mensajes que veo con problemas en redes locales,
> aqui os dejo unos consejos para que las redes os funciones bien.
>
> La mayoría de las veces no se presta atención al cableado y es el pilar
> centrar de toda instalación de red, un cableado defectuoso es causa de
> graves problemas en la red: lentitud de la red, errores en las aplicaciones,
> corrupción de indices, etc.
>
> En el mercado existen varios sistemas para comprobar que el cableado de la
> red es correcto, desde software hasta aparatos electrónicos. Lo malo de
> estas herramientas es el precio. Tambien existen empresas que se dedican a
> la instalacion de redes y hacen certificaciones del cableado usando estos
> aparatos.
>
> La instalacion del cableado debe de contemplar unas minimas normas:
>
> - Cables, rosetas de pared y terminales RJ45 compatible con la categoría 5
> (para redes de 10 Mbs) o categoría 5 mejorada (para redes de 100 Mbs).
> - Cables de red alejados de los cables de electricidad.
> - Los cables no deben formar curvas que puedan producir la rotura del cable.
> Las curvas deben ser suaves.
> - Los cables no deben estar aprisionados. Si se sujetan con abrazaderas de
> plático, no deben apretarse mucho, se corre el riesgo de cortar un
> cablecillo.
> - El trenzado final de los pares, en las rosetas de pared, no debe
> deshacerse. (El trenzado es para evitar los ruidos radio-electricos y
> electro-estaticos).
> - Los terminales RJ45 de los latiguillos de conexión deben estar
> correctamente crimpados.
> - El código de colores correcto en los RJ45 es:
> * * * * * * blanco-naranja/naranja * blanco-verde/azul * blanco-azul/verde
> blanco-marron/marron
> * * (observad que se cruzan los pares centrales)
> - Las rosetas de pared llevan dos tipos de conexionado, el correcto es el
> que va cada par combinado. Recordad que no se pueden destrenzar los cables
> para conectarlos a la roseta, se produce ruido.
> - Los cables no deberan estar por el suelo, evitando en medida de lo posible
> que sean pisados.
> - Los cables no deberan estar tensos.
>
> Como veis el cableado es primordial, si el cableado es defectuoso podeis
> usar el mejor software, las mejores tarjetas de red, los mejores switches,
> los mejores hubs, etc., que la red siempre dara problemas.
>
> Si alguien quiere más información sobre estos temas me puede contactar por
> privado a j...@oem.es.
>
> Saludos,
>
> Jose A. Suárez
> Olivares 2000
>
> *********************
>
> Regards

Dear Klas Engwall:

On Feb 9, 9:05*am, Klas Engwall <klas.engw...@nospam.please> wrote:
> > Bad hard drive (or possibly a bad hard drive controller)
> > Bad memory
> > Power outage
> > Crashed application
> > Memory overwrites
> > And finally there is the "bugs in the code" case
>
> And in addition to that: Bad network cards and/or drivers

.... and the choice of WiFi as a suitable database delivery
architecture.

David A. Smith

On Feb 8, 7:40*am, Tito <clix...@gmail.com> wrote:
> windows from 98 to Vista
> Any clues?

Just guessing here...

Check to see if you have \Windows\System\VRedir.vxd.

If so, search Microsoft's knowledgebase for an update.

Derek