Clipper On Line • Ver Tópico - Tabela DBF apaga os registros

Tabela DBF apaga os registros

Discussão sobre Banco de Dados e RDDs para Clipper/[x]Harbour.

Moderador: Moderadores

 

Tabela DBF apaga os registros

Mensagempor Jairo Maia » 09 Set 2019 15:25

Olá Pessoal,

Em 2013, publiquei essa mensagem. Chamo atenção para a última linha da mensagem. Tudo continua funcionando, mesmo depois que mudei para o RDD LetoDBf: http://www.pctoledo.com.br/forum/viewtopic.php?p=83708#p83708
Abraços, Jairo
Harbour / Clipper 5.2e - Blinker 7
(Não respondo dúvidas por MP ou E-mail. Por favor, não encaminhe via mensagem privada ou e-mail, dúvidas que podem ser compartilhadas com todos no fórum)
Avatar de usuário

Jairo Maia
Colaborador

Colaborador
 
Mensagens: 2733
Data de registro: 16 Ago 2010 13:46
Cidade/Estado: Campinas-SP
Curtiu: 371 vezes
Mens.Curtidas: 305 vezes

Tabela DBF apaga os registros

Mensagempor Itamar M. Lins Jr. » 11 Set 2019 20:35

Ola!
Com vcs a palavra de quem fez o RDD do Harbour.

Hi,

Just to clarify some myths about Clipper and Harbour behavior
presented on different Clipper related forums.

In Harbour and Clipper:

1. When record or table is unlocked then just before this
operations RDD writes all local modifications in table and
index files.
2. DBSKIP(0) just like DBGOTO( RECNO() ) writes all local
modifications (if any) and then discards local record
buffer so record has to be read again when any field is
accessed.
3. DBCOMMIT() writes all local modifications in table and
index files then it sends to system or file server request
to flush (write) its disk buffers to physical device (HARD
COMMIT). It's out of application control what OS (or FS)
do with such request.

The locking and buffer flushing in Clipper and Harbour RDDs
is safe and user cannot desynchronize data using different
instruction order, i.e. DBSKIP(0)/UNLOCK/COMMIT,...
The only problems which can appear are in OS or FS, i.e. the
infamous opportunistic locks is MSDN networks which may completely
break applications using concurrently the same files and synced
by file range and file access locks. This is the most common
reason of problems in concurrent file access in current days.

If OS (or FS) does not ignore COMMIT request then using it
reduces the time when new data exists only in file server
buffers and can be lost by server power off event so in some
cases it's good to use it. Anyhow it strongly reduce performance
so the whole operation is much longer and the chance for sudden
write process interrupt bigger. Usually the best effects can be
reached when user group some write operation and then commit them
to force buffer updates.
In harbour COMMIT can be temporally disabled by
SET( _SET_HARDCOMMIT, .F. )
and then enabled by
SET( _SET_HARDCOMMIT, .T. )
Harbour remembers which RDD files where modified with
SET( _SET_HARDCOMMIT, .F. ) so when user reenable hard commits
and call dbCommitAll() commit requesta are sent for all modified
RDD files.

best regards,
Przemek


The only problems which can appear are in OS or FS, i.e. the
infamous opportunistic locks is MSDN networks which may completely
break applications using concurrently the same files and synced
by file range and file access locks. This is the most common
reason of problems in concurrent file access in current days.

Então é tudo culpa do OS. Use Linux e seja feliz! Ou LetoDBf! E manter o DropBox atualizado!

Saudações,
Itamar M. Lins Jr.
Avatar de usuário

Itamar M. Lins Jr.
Colaborador

Colaborador
 
Mensagens: 6927
Data de registro: 30 Mai 2007 11:31
Cidade/Estado: Ilheus Bahia
Curtiu: 309 vezes
Mens.Curtidas: 503 vezes

Tabela DBF apaga os registros

Mensagempor Itamar M. Lins Jr. » 11 Set 2019 20:56

Ola!
Outra atualização em abril de 2019 que afeta a gravação do DBF.

2019-04-11 17:23 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
  * include/dbinfo.ch
  * src/rdd/dbf1.c
    + added DB_SETHEADER_EOL flag, it's used to force setting EOL marker
      when header is written. In Harbour's DBF* RDDs is set in CLOSE()
      method so just like in Clipper when DBF is closed and header has to
      be updated the EOL() marker is set.
      As side effect reducing header updates to minimal level (in such
      case DBF header is not updated after APPEND what is safe for Harbour,
      Clipper and compatible RDDs because they use file size to calculate
      number of records but some other DBF drivers may be confused)
      increase the APPEND speed and also forces EOL setting in all cases
      when CLOSE() method is called. Header updates can be reduce to minimal
      level by:
         hb_rddInfo( RDDI_SETHEADER, DB_SETHEADER_MINIMAL )

  * src/rdd/usrrdd/usrrdd.c
    ! fixed GPF in UsrRDD redirector for DROP(), EXISTS() and RENAME() methods



Saudações,
Itamar M. Lins Jr.
Avatar de usuário

Itamar M. Lins Jr.
Colaborador

Colaborador
 
Mensagens: 6927
Data de registro: 30 Mai 2007 11:31
Cidade/Estado: Ilheus Bahia
Curtiu: 309 vezes
Mens.Curtidas: 503 vezes

Anterior



Retornar para Banco de Dados

Quem está online

Usuários vendo este fórum: Nenhum usuário registrado online e 9 visitantes


Ola Amigo, espero que meu site e forum tem lhe beneficiado, com exemplos e dicas de programacao.
Entao divulgue o link da Doacao abaixo para seus amigos e redes sociais ou faça uma doacao para o site forum...
MUITO OBRIGADO PELA SUA DOACAO!
Faça uma doação para o forum
cron
v
Olá visitante, seja bem-vindo ao Fórum Clipper On Line!
Efetue o seu login ou faça o seu Registro