PC Toledo

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.

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

Código: Selecionar todos

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.

PC Toledo

Tabela DBF apaga os registros

Tabela DBF apaga os registros

Tabela DBF apaga os registros