PC Toledo

Como já comentei por aqui, nunca usei commit, sempre é SKIP 0 antes de UNLOCK.

Então, em todas as minhas rotinas, após REPLACE ... tem SKIP 0, UNLOCK.

Até aí tudo bem, mas tem situações aonde isso não é necessário.

Só relembrando antes:

"In a network environment, any record movement command, including SKIP, makes changes to the current work area visible to other applications if the current file is shared and the changes were made during an RLOCK(). To force an update to become visible without changing the current record position, use SKIP 0."

"Both FLOCK() and RLOCK() release the current lock before setting a new one"

Então podemos ter basicamente duas situações diferentes:

1 - Por exemplo alterar o cadastro de um cliente e continuar posicionado nele

Neste caso, melhor o SKIP 0 e UNLOCK, pra ficar visível pras demais estações

2 - Processamento seguido
Nesse caso dá pra eliminar o SKIP 0 em cada registro porque já tem um SKIP, e dá pra eliminar o UNLOCK porque o próximo RLock() já faz isso.

Conclusão:

Talvez dê pra agilizar algumas rotinas, eliminando SKIP 0 e UNLOCK em determinadas situações.

Tem que pensar nestas três coisas:
- Enquanto o terminal que gravou no arquivo não fizer SKIP ou outra movimentação, não vai ficar visível em outro terminal
- Enquanto não bloquear um novo registro, o anterior não vai ser liberado
- Quanto tempo a rotina vai precisar pra deixar visível ou desbloqueado pra outros terminais.

Aproveitei pra compartilhar a "nova velha descoberta", que não tinha reparado antes.
Provavelmente consiga remover SKIP 0/UNLOCK de algumas rotinas.

JoséQuintas escreveu:Neste caso, melhor o SKIP 0 e UNLOCK, pra ficar visível pras demais estações

Quando as estações estão em um DBEDIT() (não uso o TBrowse) a alteração fica "disponível" quando se movimenta o browse.

Alguns problemas que notei nisso:

1- Se seu DBEDIT retornar RETURN 1 ele não atualiza a tela inteira, somente o registro atual.
2- Se seu DBEDIT ficar retornando RETURN 2 ele atualiza a tela porém sobrecarrega o browse.
3- Se estiver no DBEDIT com o cursor sobre um registro e em outro terminal houver uma "exclusão" possivelmente no terminal que estava com o ponteiro sobre ele poderá travar caso na sua função de controle
do DBEDIT retorne 1. Agora não lembro se estava com algum indice ativo nesse momento.

Enfim, sempre procurei alguma forma de atualizar o DBEDIT em rede mesmo que fosse quando o usuário navegasse nele. Para isso tinha que ter um algoritimo que permitisse saber o momento exato de usar o RETURN 2 sem sobrecarregá-lo.

Foi então que comecei a monitorar a data de alteração do arquivo de dados, através dela a cada gravação em rede faço uma comparação e se houver diferença uso o RETURN 2. Tem dado muito certo, inclusive o sistema ficou mais rápido em rede assim comentaram meus clientes, visto que a maior parte do tempo, o DBEDIT fica com RETURN 1, ou seja, não faz nada.

JoséQuintas escreveu: dá pra eliminar o UNLOCK porque o próximo RLock() já faz isso.

É isso mesmo, cada RLock() anula o anterior, descobri isso tentando otimizar minhas gravações e não consegui travar mais de 1 registro para o replace. A equipe do Clipper/[x]Harbour poderiam ter pensado nessa ocasião.

Ate+

Olá!

ANDRIL escreveu:É isso mesmo, cada RLock() anula o anterior...

Cumpre o que diz o manual

RLOCK()
Lock the current record in the active work area

ANDRIL escreveu:A equipe do Clipper/[x]Harbour poderiam ter pensado nessa ocasião.

Não é bem assim... tanto pensaram que criaram funções para tratar estas situações, a partir da versão 5.3 do Clipper. Certamente o Harbour e xHarbour as trouxeram:

DBRLOCK()
Lock the record at the current or specified identity

DBRLOCKLIST()
Return an array of the current lock list

DBRUNLOCK()
Release all or specified record locks

Segundo o help do xHarbour, o COMMIT “writes memory buffers of all used work areas to disk” e também faz com que “changes to the data become visible to other processes in a network environment”. Já o SKIP 0 só “make changes to a record visible to other work stations while a record is locked”.

Eu sempre uso o DBCommit(), que é igual ao COMMIT mas atua só na área de trabalho atual, pra assegurar que as alterações em cache (na memória) sejam gravadas em disco e fiquem visíveis na rede.

É isso mesmo, cada RLock() anula o anterior, descobri isso tentando otimizar minhas gravações e não consegui travar mais de 1 registro para o replace. A equipe do Clipper/[x]Harbour poderiam ter pensado nessa ocasião.

Não sei do Harbour, mas o xHarbour tem o DBrLock(), DBrUnlock(), DBrLockList() etc. Dá pra gravar n registros não consecutivos, ver a lista dos registros bloqueados, desbloquear um ou mais registros da lista etc.

“processamento seguido”

Eu evito usar RLock() e replace em processamento seguido, como apontado pelo José Quintas, até porque dois usuários podem inventar de fazer a mesma coisa ao mesmo tempo... Se uma alteração vai envolver mais de um registro, uso FLock(). E, se o REPLACE vai mexer em só um registro, mas de um campo indexado, é FLock() e DbCommit().

alxsts escreveu:a partir da versão 5.3 do Clipper

Realmente tem isso no xHarbour vi no Help agora. Use Clipper até a 5.2e e sempre senti falta dessas funções, valeu pela dica.

Eolo escreveu:processamento seguido

No meu caso, evito usar o DbCommit() seguido a cada replace, após terminar o loop dou um único comite para a área de trabalho ativa. Isso alivia muito o processamento do loop.

Ate+

Olá!

Na verdade, DbSkip(0) faz uma releitura do disco e atualiza os buffers de leitura do aplicativo em execução. É o inverso de DbCommit().

Já comentei por aqui:

Cheguei a usar Clipper + SIXCDX
simultâneo com VB6 + ADS

No VB6/ADS a atualização do Clipper só ficava visível depois do SKIP 0 no Clipper.
Podia consultar o registro inúmeras vezes no VB6+ADS, mas só aparecia atualizado após o SKIP 0 no Clipper.
( SKIP 0 no caso do Clipper continuar parado no mesmo registro )

Ok, o SKIP 0 pode fazer a "releitura do registro", mas além disso salva as alterações.
Confirmado na prática ao usar simultâneo com VB6+ADS.

O inverso era instantâneo, ao alterar no VB6, o Clipper já enxergava tudo atualizado. (no VB6 sempre por comandos SQL).

Pra mim, no meu caso, falta testar se o COMMIT faz o mesmo que o SKIP 0.
Se ele atualizar no disco inclusive o registro atual, seria mais rápido que SKIP 0, porque não teria a releitura.
Só depois de testar isso eu elimino o SKIP 0.

Faz tanto tempo que uso assim, que não lembro se foi pelo COMMIT não fazer isso.

Uia o que tenho aqui, ainda inteiro....
Clipper 5.0 em 7 discos 5 1/4, e .RTLINK 7.10 em 3 discos 3 1/2
E um trecho interessante:

Tem esta nota. Fiquei no mesmo.
Pode ser que na SIXCDX seja diferente, mas vou precisar do teste prático.
Nesse caso o manual não ajudou.
Lembrando que no meu uso prático, o UNLOCK, ao contrário do que diz no manual, não deixou as alterações visíveis para o ADS.

Nota:
Acredito que estes trechos sejam tão básicos e pequenos, que não exista problema em mostrá-los.

Fugir do tópico, e colocar algumas coisas que me chamaram a atenção:

Driver fornecido:
- Até 1 bilhão de registros por arquivo
- Até 1024 campos por registro
- Até 15 índices ativos por arquivo de dados em uso
- Arquivos de índice com chaves até 250 caracteres, ou compatíveis com dBASE até 100 caracteres
- Campos caractere até 32K caracteres tamanho fixo
- Campos memo até 64k
- Campos numéricos até 30 dígitos ( precisão >= 16 dígitos significativos )

Variáveis:
- Caractere até 64K
- Até 2048 variáveis PUBLIC/PRIVATE
- Variáveis LOCAL/STATIC limite = memória disponível
- Vetores com até 4096 elementos por dimensão, dimensões ilimitadas limite = memória disponível
- Campos numéricos até 30 dígitos ( precisão >= 16 dígitos significativos )


Nota:
Na caixa está que a precisão numérica é MAIOR ou IGUAL a 16 dígitos significativos.
Provavelmente significa que 16 são garantidos, mas pode chegar a 30.

Quando vi a foto acima, bateu uma lembrança muito boa, estão praticamente intáctos José. Remete ao tempo em que o conhecimento era buscado quase exclusivamente nos livros e lembro das minhas visitas às livrarias em buscas de novidades sobre o Clipper. Vinha do FoxBase e não tinha muito conhecimento quando ouvi falar do clipper gerador de executáveis... que beleza era isso! Lembranças...
PS: me chamou atenção o tamanho do "Pocket" (livro branco), rs!
Ate+

Amiguinhos,

Esta coisas só mostram que estamos ficando velhos. O tempo de se programar digitando kilômetros de códigos existentes nos livros chamados de Biblias, já se foram, mas nos deram, audodidáticamente muito conhecimento, não tinhamos preguiça e o café era mais gostoso.

Programação da forma como fazemos pode ser omparada com boctha, aquele jogo com bolas de ferro pesadíssimas, ka, ka, ka.

Mas fala sério, por mais que tenhamos passado por isto, ainda nos dias de hoje encontramos novidades.

Eu uso muito o dbSkip(0) mas o dbRListLock() me é novidade. Como nunca mais tive problemas com travamentos e destravamentos não pesquisei mais, mas a existência de funções só nos mostram que elas não estão lá por mera perfumaria.

Rochinha,

Estas funções pra mim também são novidades. Mas eu ainda não consegui pensar numa situação em que seja necessário o uso de alguma dessas funções.

Pelo que mim parece, DBRUNLOCK() eh o mesmo que DbUnLockAll(). Não sei.

Pois é.
O Harbour tem muito mais funções que o Clipper.
Se no Clipper, 20 anos depois ainda tem coisa que não usamos... no Harbour então...

Sobre o "Pocket", não é "de bolso", era o nome da empresa mesmo.