Skip 0

[billy1943]

Em muitos exemplos de fontes exibibidos neste e em outros Fóruns sobre Clipper, vejo muitas vezes o uso de SKIP 0.
Eu não uso o comando SKIP mas sim a função DBSKIP(), com valores positivos ou negativos dentro do parênteses.

Quando podemos usar e para que serve SKIP 0 ?

[Maligno]

O valor zero para SKIP não tem efeito de salto entre registros. O efeito é bem diferente e igual ao do comando COMMIT: dar um flush ou descarregar os dados em disco.

[alxsts]

Saudações a todos!

Maligno escreveu:
...O efeito é bem diferente e igual ao do comando COMMIT: dar um flush ou descarregar os dados em disco.

Perdoe-me o caríssimo Maligno mas, voce tem certeza?

Sem nenhuma intenção de gerar uma polêmica, e pelo que conheço de xBase, tanto o comando SKIP n quanto a função DbSkip(n), admitem um parâmetro, que representa a quantidade de registros a ler. Sim, LER e não efetivar a gravação em disco.

Sem parâmetros, ela assume o default 1 e lê o registro seguinte, se existir (ou seja: .Not. Eof()).
Se o parâmetro informado for -1, lê o registro anterior, se existir (ou seja: .Not. Bof()).
Se o parâmetro informado for 0, lê o registro atual, ou seja, executa uma releitura do registro préviamente lido.

Isso é muito útil em ambiente de rede e recomenda-se fortemente a sua execução imediatamente antes de um RLock() para garantir, por exemplo, que o registro que iremos alterar é a última versão do mesmo

[Maligno]

Sim, tenho certeza. Como você disse, SKIP 0 faz realmente a releitura do registro atualmente apontado. O que é totalmente inútil em nível local, a não ser pelo efeito que mencionei: 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.

Palavras do NG:
"To force an update to become visible without changing the current record position, use SKIP 0. "

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.

[ANDRIL]

Palavras de Eduard Tiley:

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)

Ate+,

[Maligno]

Difícil seria comprovar essa informação. De qualquer forma, COMMIT é sempre melhor.

[alxsts]

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.

[Maligno]

Como eu disse, acho que o COMMIT é melhor que o SKIP 0; comando este que nunca usei. Apesar de que eles têm o mesmo efeito, de acordo com o NG.

Ademais, se o RLock() falhar e se tudo tiver sido feito certo, significa que ainda não temos o destravamento, e nem os dados atualizados. Quando o destravamento tiver sido feito, já posso admitir que os dados estão atualizados. Faço o RLock() e trabalho em cima do registro, lido para uma matriz (meu modo). Lembro de um dia (faz muito tempo) ter tido a dúvida se os dados viriam atualizados ou não. Vinham. Sem a necessidade de um SKIP 0 para uma releitura. Logo, pra mim, sempre foi desnecessário. A trinca LOCK->COMMIT->UNLOCK era suficiente. Até porque, eu primeiro faço o bloqueio e só depois acesso o registro, o que me garante pegar os dados atualizados. Mas veja: nada impede um SKIP 0 adicional (para quem quiser), mesmo que desnecessário. Não fará mal algum.

o ideal é fazer o DBSkip(0) e em seguida o RLock()

Pela sua lógica, acho que o ideal é fazer o SKIP 0 só depois do RLOCK retornar TRUE. Senão, pra que serviria reler o registro do disco se não poderá editá-lo?

Mas não vou me alongar nessa questão, pois pra mim isso já é parte do passado, felizmente. Já não programo mais em Clipper.

[ANDRIL]

Sobre Eduard Tiley, na verdade W. Eduard Tiley, é autor de vários livros sobre DBase, Clipper, DOS dentre outros, verdadeiras "biblias". Eu particulamente uso o livro "Usando Clipper", muito bom por sinal.

Ate+

[billy1943]

Que legal !!

Ficou demonstrado acima que as respostas à dúvida por mim iniciada, no uso de um comando (SKIP) ou uma função (DBSKIP()), há anos no repertório de nós Clippeiros de carteirinha, poderia ser tão proveitosa.

O meu livro do W. Edward Tiley é de 1992, faz 17 anos que o consulto e sempre me aparece uma dúvida, o que me levou a iniciar o tópico.

Pelo que os colegas com conhecimento e análise expuzeram, fico com o trio que nunca me deu problemas nos meus sistemas em rede, sem a necessidade do Skip 0:

Rlock
....
Commit
Unlock

E Viva o Clipper !!

[victorale07]

Hola
Eu posso enviar link para baixar o livro

[billy1943]

Como meu livro é da versão 5.00 melhorada para 5.01, se quiser me mandar o link de edição mais moderna, aí vai meu e-mail:

agua.nova@hotmail.com

[Maligno]

Se o colega quiser, posso subir o eBook pro meu site. Assim fica disponível pra todo mundo.

[SandroBelarmino]

Se o colega quiser, posso subir o eBook pro meu site. Assim fica disponível pra todo mundo.

Maligno, se voce fizesse isso seria bom demais heim !
Valeu.
Sandro

[Maligno]

É só o colega passar o link.