Tabela DBF apaga os registros

[leandromilersantana]

vou começar a testar desta forma. Vamos ver os resultados !!!

[Fernando queiroz]

Faltou dizer:

NUNCA USEI COMMIT, nem dbcommit(), apenas SKIP 0 antes do UNLOCK.
Não tive problema nem com Visual Basic 6 acessando simultâneo.
SIXCDX no Clipper 5.2, SIXCDX no início de uso do Harbour, DBFCDX depois.

Quintas como você faz a limpeza dos registros deletados no DBF?? ( ainda uso o pack)

[JoséQuintas]

Quintas como você faz a limpeza dos registros deletados no DBF?? ( ainda uso o pack)

Como eu disse, minha reindexação faz COPY/APPEND e não PACK.
Mas... como eu também disse.... fica por conta do cliente, que pode nunca fazer a reindexação.

Eventualmente, numa atualização de versão/estrutura, isso acaba sendo feito ao atualizar estrutura.

Pensando bem....
Excluir alguma coisa é uma exceção, e não algo que se faz o tempo todo.

Então temos uma nova pergunta:
Porque a preocupação de limpar os excluídos?
Porque tem tanta coisa excluída?

[Ranier]

Senhores.
https://harbour.github.io/doc/harbour.html#dbcommit
IF Updated()
dbAppend()
test->first := cName
test->age := nAge
dbCommit()
ENDIF

dbCommit para no meu entendimento, é o correto a ser usado em append/replace.

dbSkip(0)
"A dbSkip( 0 ) will flush and refresh the internal database buffer and make any changes made to the record visible without moving the record pointer in either direction."

Uso para reler (refresh) os dados do registro em disco (dbf) para a memória.

Quanto ao problema, use mapeamento somente em Windows Servers (2003, 2008, etc) ou em SAMBA (linux),
nunca com windows normal, pq esses têm limitações impostas pela própria Microsoft, para não canibalizarem os
servers.

[JoséQuintas]

dbSkip(0)"A dbSkip( 0 ) will flush and refresh the internal database buffer and make any changes made to the record visible without moving the record pointer in either direction."

Vamos destacar uma parte:

make any changes made to the record visible

Deixa qualquer alteração visível para outros.

Foi exatamente nisso que me baseei desde sempre.
Se está visível para os outros da rede.... logicamente está salvo.

[Ranier]

"make any changes made to the record visible"
Com relação a parte destacada, as alterações a que se refere o manuel é a respeito das alterações
feitas por outros processos/usuários, do arquivo dbf.
A intenção do programador que fez o comportamento de dbSkip(0) é bem clara, lhe traz as possíveis
alterações feitas pela rede.
Com certeza é um efeito colateral, gravar possíveis alterações feitas pelo seu processo, porquê
nas funções do driver rdd (dbfcdx), toda e qualquer rotina, chama a rotina que grava possíveis
alterações feitos pelo processo atual.
Mas a rotina feita para somente gravar e desmarcar o flag que sinaliza alterações é a dbCommit.

Pelo menos, é o que eu entendi debruçando sobre o código do DBFCDX para fazer o DBDRDD,
e esse é o comportamento adotado de quando chama dbCommit (grava todas as alterações feitas, no SGDB).

em tempo:
O DBDRDD não é copy/paste do DBFCDX, eu aroveitei somente a lógica (api) para fazer total compatibilidade.
O DBDRDD faz exatamente o que DBFCDX faz mas com SGDB (Banco de Dados).

[JoséQuintas]

dbCommit() causes all updates to the current work area to be written to disk. All updated database and index buffers are written to DOS and a DOS COMMIT request is issued for the database (.dbf) file and any index files associated with the work area.

faz com que TODAS as atualizações na área atual sejam gravadas em disco. Todas as atualizações em banco de dados e índices são gravados para o DOS, e uma requisição de gravação 's solicitada para o banco de dados e índices associados com a área atual.

Me parece um negócio bem mais pesado.
Se não me engano, no Clipper ainda vinha o extra de "força a gravação".
Algo como gravar em disco pra não perder nada.

Em todo caso, acho que já fiz isso antes, vou olhar o manual.

[JoséQuintas]

Na verdade confundiu.
Um arquivo exclusivo, ao usar COMMIT fica visível aos outros usuários? Mas como? deixa de ser exclusivo?

Se seguir ao pé da letra, não precisa nem COMMIT nem SKIP 0.
Alguém se habilita a isso?

Se as rotinas de incluir/alterar são únicas pra compartilhado/exclusivo, melhor o SKIP 0.
COMMIT poderia retirar o arquivo de modo exclusivo, seria isso?

Se seguir ao pé da letra, só vale pra DBF/NTX.

Conclusão:
TODOS concordam que o manual está errado, porque somente UNLOCK causa problemas.
Sendo assim, continuarei usando SKIP 0, e vocês continuarão usando COMMIT.

[JoséQuintas]

TODOS concordam que o manual está errado, porque somente UNLOCK causa problemas.

Correção:

O manual diz que é só pra DBF/NTX, mesmo assim, o manual é do Clipper 5.0, que inicialmente nem tinha DBF/CDX, e também os drivers foram substituídos depois pelos de outra empresa, o próprio manual já diz que pode não ser válido para os demais drivers.

O manual diz que não precisa nada... com certeza é mentira.
O manual diz que COMMIT, SKIP, GOTO, todos atualizam.

No simultâneo com Visual Basic, no Clipper só UNLOCK não ficava visível, precisava do SKIP 0.
NUNCA usei COMMIT, nem mesmo pra um teste sequer, só posso dizer que com SKIP 0 funciona.
COMMIT funciona? não faço a menor idéia.

[Ranier]

Afinal estamos falando do Harbour/DBFCDX?

HB_FUNC( DBCOMMIT )
{
AREAP pArea = ( AREAP ) hb_rddGetCurrentWorkAreaPointer();

if( pArea )
SELF_FLUSH( pArea );
else
hb_errRT_DBCMD( EG_NOTABLE, EDBCMD_NOTABLE, NULL, HB_ERR_FUNCNAME );
}

Que chama SELF_FLUSH( pArea )

Que em DBFCDX eh:
static HB_ERRCODE hb_cdxFlush( CDXAREAP pArea )
{
LPCDXINDEX pIndex;
HB_ERRCODE errCode;

HB_TRACE( HB_TR_DEBUG, ( "hb_cdxFlush(%p)", ( void * ) pArea ) );

if( SELF_GOCOLD( &pArea->dbfarea.area ) == HB_FAILURE )
return HB_FAILURE;

errCode = SUPER_FLUSH( &pArea->dbfarea.area );

if( hb_setGetHardCommit() )
{
pIndex = pArea->lpIndexes;
while( pIndex )
{
if( pIndex->pFile && pIndex->fFlush )
{
hb_fileCommit( pIndex->pFile );
pIndex->fFlush = HB_FALSE;
}
pIndex = pIndex->pNext;
}
}

return errCode;
}

Que chama SUPER_FLUSH,
que em dbf1.c:

static HB_ERRCODE hb_dbfFlush( DBFAREAP pArea )
{
HB_ERRCODE errCode;

HB_TRACE( HB_TR_DEBUG, ( "hb_dbfFlush(%p)", ( void * ) pArea ) );

errCode = SELF_GOCOLD( &pArea->area );
if( errCode == HB_SUCCESS )
{
if( pArea->fUpdateHeader && ( pArea->uiSetHeader & DB_SETHEADER_COMMIT ) != 0 )
errCode = SELF_WRITEDBHEADER( &pArea->area );
}

if( hb_setGetHardCommit() && errCode == HB_SUCCESS )
{
if( pArea->fDataFlush )
{
hb_fileCommit( pArea->pDataFile );
pArea->fDataFlush = HB_FALSE;
}
if( pArea->fHasMemo && pArea->pMemoFile && pArea->fMemoFlush )
{
hb_fileCommit( pArea->pMemoFile );
pArea->fMemoFlush = HB_FALSE;
}
}

return errCode;
}

enfim, que chama hb_fileCommit(), que finalmente escreve em disco.

Acho que tem bastante da palavra "flush", que pode significar descarga.
Afinal, para que o programador da RDD iria chamar commit se não é para que grave os dados.

Usando DBSkip(0), o programa está sujeito a seguinte falha, rara, mas possível.
Processo A Processo B
update buffer Y update buffer Y
dbskip(0), reload buffer from disk dbcommit, write buffer to disk

Após dbSkip(0), o buffer será relido, que possivelmente, pode ter sido modificado pelo processo B,
entao o programa do Processo A, agora tem os dados gravados pelo Processo B, e não os dados que ele
pensa ter acabado de gravar.

[Ranier]

Vou tentar resumir a questão:
Ao chamar dbSkip(0), implicitamente, também está sendo chamado dbCommit (flush).
Dessa forma, o sistema é penalizado e fica sujeito a erros (raros).

Usar dbSkip(0) para gravar as alterações é mesmo que:
update -> flush -> reload

em sql
update -> select

Assim, toca-se disco, subsistema de rede duas vezes. Péssimo para performance em geral.
Acredito que ao criarem a RDD e (dbfcdx), o princípio KISS não foi seguido, talvez, pela fragilidade
do sistema de rede da época (DOS/NOVELL).
Afinal cada função deveria fazer uma única coisa e só.
Talvez nunca aconteça, pq quase ninguém mexe no código do Harbour agora, mas alguém poderia
mudar o comportamento da API e fazer cada função fazer somente o que deveria fazer.

dbSkip(0), reler o buffer do disco para a memória, pronto.

[Itamar M. Lins Jr.]

Ola!
Se não me falha a memória já li alhures o Przmek dizendo que skip(0) não faz o que o commit faz. Vou ver se acho isso.
Mas quem já usa LetoDbf não se preocupa com isso. Rede mapeada é só problema.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Se não me falha a memória já li alhures o Przmek dizendo que skip(0) não faz o que o commit faz. Vou ver se acho isso.

Se não me engano, isso foi depois de um post meu, recomendando a mesma coisa no harbour-users.
Mas.... 30 anos usando sem problemas.
Sempre que alguém posta sobre problema está usando COMMIT, então nunca me preocupei em testar se o resultado vai ser o mesmo.

Código: Selecionar todos

FUNCTION RecUnlock()

   SKIP 0
   UNLOCK

   RETURN NIL

Pra alterar TODOS os meus aplicativos, seria alterar apenas essa linha acima.
Opções:
deixar assim, continua tudo funcionando
Alterar: pode não ter diferença, mas pode dar problema
Então... deixar assim, e me preocupar com coisas mais importantes.

Usar numa única função, isso sim é vantagem, porque nunca inverte a ordem, nunca esquece de nenhum, e substitui dois comandos por um único, reduzindo o tamanho do EXE.

Quem está com problemas pode testar usando COMMIT ou SKIP 0, e até trocando pra uma única função, assim pode alterar depois sem ter que passar por cada fonte novamente.

Mas acho que dá pra fazer um teste simples.... vou ver aqui.

[JoséQuintas]

kkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkk

Num teste simples, qualquer um atualiza: UNLOCK, COMMIT; SKIP 0

Código: Selecionar todos

#include "inkey.ch"

PROCEDURE Main

   LOCAL mNome, GetList := {}, mSalva

   SetMode(40,100)
   CLS
   IF ! File( "test.dbf" )
      dbCreate( "test.dbf", { { "NOME", "C", 30, 0 } } )
   ENDIF
   USE test SHARED
   IF Eof()
      APPEND BLANK
      REPLACE field->NOME WITH "1111111111"
      APPEND BLANK
      REPLACE field->NOME WITH "2222222222"
   ENDIF
   GOTO TOP
   DO WHILE .T.
      mNome  := test->Nome
      mSalva := " "
      @ 2, 1 SAY "Nome:" GET mNome
      @ 3, 1 GET mSalva PICTURE "!"
      @ Row(), Col() + 2 SAY "(C=Commit, S=Skip 0, U=Unlock, N=Nenhum)"
      READ
      IF LastKey() == K_ESC
         EXIT
      ENDIF
      IF mSalva $ "CSUN"
         RLock()
         REPLACE NOME WITH mNome
         DO CASE
         CASE mSalva == "C"; COMMIT; @ 5, 5 SAY "COMMIT"
         CASE mSalva == "S"; SKIP 0; @ 5, 5 SAY "SKIP 0"
         CASE mSalva == "U"; UNLOCK; @ 5, 5 SAY "UNLOCK"
         OTHERWISE         ;         @ 5, 5 SAY "      "
         ENDCASE
      ENDIF
      SKIP 0
   ENDDO
   CLOSE DATABASES

   RETURN

kkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkk

Mas aposto que este vocês não sabiam, e NÃO serve COMMIT.
E deve ser esta a causa de seus problemas !!!!!!

Código: Selecionar todos

RLOCK()
SKIP 0

[Jairo Maia]

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: https://pctoledo.org/forum/viewto ... 708#p83708