Saudações a todos!
Caro Maligno:
Primeiramente, é um prazer debater algo com um dos baluartes deste forum, com quem estou sempre aprendendo. Feliz Dia do Programador, para todos nós!
Como sabemos, a questão da concorrência no acesso às informações contidas em uma base de dados é sempre palpitante. Se em Clipper já nos deparamos com isto, o que dizer do que ocorre em um banco de dados relacional? Como controlar um Begin Transaction, milhares de inserts ou updates ou deletes na mesma transação e depois um Commit Transaction ou RollBack? Tudo isto ao mesmo tempo que outras milhares de transações, sem comprometer a integridade de um todo... Cada vez mais pessoas acessam sitemas que às vezes, no mesmo instante, tem que acessar a mesma peça de informação, dentre milhões delas.
Voltando à dúvida do nosso amigo Billy1943, concordo com o que voce disse, " - é totalmente inútil em nível local". Realmente, a questão só existe quando mais de um interessado acessa a mesma informação e ao mesmo tempo.
Maligno escreveu
ANTES dessa releitura é feita a descarga para o disco, justamente para tornar os dados recém gravados visíveis num provável ambiente de rede. Logo, é o mesmo efeito que um simples COMMIT
De certa forma, concordo mas, acho que a questão está colocada de forma confusa, não para mim. Parece que se está a confundir entrada e saída, duas operações básicas em processamento eletrônico de dados. Vou tentar esmiuçar mais. Perdoem...
Sei que voce lê e escreve em inglês (provavelmente tambem fale) pois já li respostas suas nesta língua a posts escritos na mesma. Talvez, algum dos colegas não tenha a mesma habilidade e, por isto, traduzo o texto do NG, por voce citado, para melhor entendimento:
Palavras do NG:
"To force an update to become visible without changing the current record position, use SKIP 0."
"Para forçar uma atualização a se tornar visível sem alterar a posição do registro corrente, use SKIP 0" ---> por posição, entenda-se (Recno())
Imagine que dois usuários estejam tratando o mesmo registro de uma mesma tabela, no mesmo instante:
Se estou executando uma leitura refresh (DBSkip(0)), não atualizei nada. Neste ponto, pergunto: Se alguem atualizou, quem foi? Talvez, o outro usuário. Onde entra o COMMIT ou DbCommit()? Talvez o outro usuário tenha emitido esse comando. Por que emitir um DBSkip(0)? Para ler a última posição do outro usuário no registro. Por isso, eu escrevi anteriormente, que o ideal é fazer o DBSkip(0) e em seguida o RLock(). Se o RLock() falhar, o outro usuário ainda não fez o DBCommit(), DBUnlock() e então, poderei tratar o erro.
\E esqueci de mencionar que nem isso é garantido (nunca usei SKIP 0), já que há uma limitação, o que torna COMMIT muito mais recomendável. Continuando as palavras do NG:
"If, however, the changes were made during an FLOCK(), visibility is not guaranteed until the lock is released, a COMMIT is performed, or the file is closed."
"Se, no entanto, as alterações foram feitas durante (a vigência de) um FLOCK(), a visibilidade não é garantida até que o "lock" seja liberado, um COMMIT seja efetuado ou o arquivo seja fechado.
Da mesma forma, se existir um FLock() por parte do outro usuário, posso fazer um DBSkip(0) sem problemas mas, o RLock() falhará pois o outro usuário ainda não fez o DBCloseArea() ou DBUnlock(), para remover o FLock(). Se o outro usuário estiver gravando em um arquivo que tenha um FLock() ativo, a execução de COMMIT ou DBCommit(), apenas torna as atualizações dele visíveis a outos usuários da rede mas, não remove o FLock().
Andril escreveu:
SKIP 0 pode ser usado para colocar as informações dos buffers internos do Clipper nos buffers do DOS, mas não faz com que o DOS grave o conteúdo dos seus buffers em disco. Use o comando COMMIT para isto (apartir da versao 3.3 do DOS)
Não conheço o autor citado (Eduard Tiley).
Creio que tanto o Clipper, como o DOS e, óbviamente o Windows, tem buffers tanto de entrada quanto de saída... Creio tambem que SKIP n e DBSkip(n) tragam dados do disco para os buffers de entrada do DOS e Clipper. REPLACE descarrega os buffers do Clipper no Dos e COMMIT força a gravaçâo destes no disco.
Creio então que COMMIT não é melhor que SKIP por se tratar de coisas diferentes.
