PC Toledo

Acho que o colega quis dizer que está com problema com bloqueios, liberações, etc. Quando se programa em rede, no começo é meio estranho mesmo.

Netavin, se der conta do recado sozinho, tanto melhor. Mas se der algum problema, poste o seu código de tratamento de bloqueios. Normalmente a coisa enrosca aí.

Netvin, se vc der uma olhada no link que postei...lah tem tudo ou quase tudo que vai prescissar para deixar seu sistema Mult-usuario...

Maligno escreveu:Acho que o colega quis dizer que está com problema com bloqueios, liberações, etc.

Agora entendi...
Realmente, é neste ponto que ocorrem os primeiros problemas.

Tambem estou começando a programar em rede mas ja da pra ir te adiantando umas coisas

comandos que voce vai usar para trabalhar com redes"permissões"

use clientes exclusive // aqui voce abre o banco de dados exclusivo nenhuma outra estação concegue abrir este banco quando voce o abre em modo exclusivo , isso deve ser usado para caso de indexar o banco de dados e para que mais serve ?? Não sei ...
....................................................................

use clientes shared // Dessa forma voce abre o banco compartilhado de forma que todas as estações possam abrir o mesmo banco de dados
.....................................................................

Rlock() // Essa função se usa no caso de alterações em unico arquivo do banco de dados "o cara vai faz a pesquisa no banco de dados , se achou o que queria , sei la teclou F2 para alterar ae sim RLOCK
trava apenas o registro que voce esta usando e o restando dos resgistros para a area de atrabalho atual ficam liberados para os demais usuarios ; O registro que voce esta alterando só sera liberado após o DBunlock()
......................................................................
Flock() // Essa função se usa no caso de inclusões no banco de dados ela trava o banco por completo de forma que ninguem mais consegue alterar ou apagar qualquer registro ninguem consegue acesso a este banco até que voce o libere por um BDunlock()
......................................................................
Comitt() // grava as alterações ou inclusões no DB apos a confirmação assim após ser gravado ja esta disponivel para todos

DBunlock() // destravava o banco de dados , libera a restrição de Rlock(), Flock()
.......................................
funções que uso

Código: Selecionar todos

*****<trava unico mregistro para alteraçao/exclu>******
static func travrecor()                             
priv ok:=.f.
priv teste:=0
do while teste++ <=3
   if Rlock()
      ok=.t.
      exit
   endif
   inkey(1)
enddo
if ok=.f.
   Alert("Maligno travou o banco de dados; tente mais tarde!")
endif
return ok


********<trava DB para ediçao>***********

static func travarq()
priv ok:=.f.
priv teste:=0
do while teste++ <=3
   if flock()
      ok=.t.
      exit
   endif
   inkey(1)
enddo
if ok=.f.
   Alert("maligno travou o banco de dados, tente mais tarde")
endif
return ok

Pois bem que venham, as criticas ....

:|<

"maligno travou o banco de dados"

Espero que esse aí seja só um homônimo.

))

Não sei se essas rotinas são pra valer ou apenas uma demonstração ou teste. Mas se for pra valer, tenho só um crítica que, aliás, nada tem a ver com rede em si. Mas acho que se não servir pra você, poderá servir a outros colegas.

Funções, operacionalmente, deveriam realizar apenas uma e tão somente uma tarefa. Se é pra bloquear, apenas bloqueia. Se falhar, não bloqueia e não apresenta alerta nenhum. Apenas retorna o resultado da operação. Mas e o alerta? Alerta é interface. Deveria ficar numa função de interface, que chama a função de bloqueio e analisa seu resultado. Porque isso? Porque se amanhã ou depois você mudar a interface, não precisa mexer naquilo que já estava testado e comprovado. É o que se chama de unicidade de uma função. Manter essa unicidade é ajudar a si próprio a evitar problemas. É o exemplo da validação de CNPJ. Se falha o camarada já solta um bip ali mesmo. Vira uma salada. É por isso que existe o termo "caixa preta". Você só tem entrada e saída. O que acontece ali dentro já não interessa mais. Só interessa às demais funções conhecer detalhes das entradas e saídas da "caixa preta". O conteúdo dela não.

Isso não é coisa que eu estou inventando. É parte do conhecimento acumulado nessa área ao longo de muitos anos. Então, porque não aprender com os erros dos outros?

Um complemento: é claro que, em boa parte dos casos, digo, nas funções de nível mais alto, não é possível querer essa unicidade nas funções. Mas em funções de baixo nível, como a do seu exemplo, é aconselhável manter o conceito de "caixa preta".
Em Clipper, inclusive, isso nem é tão crítico. Mas o ditado diz "O hábito faz o monge". É sempre uma boa idéia cultivar bons hábitos, pois quando for pra migrar para OOP, a coisa vai complicar consideravelmente. O paradigma OOP já é um fator de complicação. Adicionar outro não é uma boa idéia. Métodos de uma classe que tratem de tarefas em baixo nível, se não forem implementadas com esses cuidados, acabam se tornando fontes de muitos problemas. Evitar esses problemas envolve conceitos simples, como esse. E agrega valor ao código, tornando, por exemplo, a manutenção muito mais simples.

Boa tarde amigos!

Mataram a pau ! É aí que está o enrosco. Já li sobre tudo isso que voces falaram.
Fiz implementações necessárias, de acordo com os exemplos que me mostraram. Devo estar me embananando em algum ponto. Mas tudo bem. Deixa eu tentar mais um pouco. Se tudo o mais falhar, eu apelo mesmo. Blz ?
O meu maior empecilho no momento é a falta de tempo. Vou para o trabalho às 6:30 e saio às 22:00, é mole ? E se eu não dormir ....

Valeu amigos!

Nos falamos...

[]´s

Netavin

PC Toledo

CLIPPER5.3 EM REDE WIN XP

REDE XP