mudança de dbf para sql

[edutraini]

Bom dia Pessoal 

Estou mudando o meu sistema de dbf para sql 

Gostaria de tirar uma duvida em relação a logica de trabalhar com SQL.

No Dbf eu travava o registro para que outro usuario nao tivesse acesso a mesma informacao que estava sendo editada o famoso rl()

Qual melhor logica para trabalhar no SQL

Exemplo : Tenho um agenda de medicos com seu devidos horarios .Alguem liga para marca uma consulta as 8:00 hs, para que dois atendentes, nao marquem no mesmo horario.

Eu faço a consistencia na hora de gravar ou seja alguem vai primeiro ?

Como vcs trabalham nessa situacao

Obrigado

 

[Ladinilson]

Bom dia,

Como já foi sugerido aqui neste forum, sugiro usar o SQLRDD com pequenas alterações em seus fontes e aos poucos, mudando para os comandos nativos do SQL como eu fiz.

Nas novas versões já tem a conexão com o MariaDB  que não estudei ainda, mas acredito que deve ser bem mais produtivo.

Boa Sorte!

[emotta]

Sugiro criar um semafaro antes de checar a existencia do registro. Você checa a existencia e não existindo você grava e libera o semafaro.

Se já existir vc libera o semafaro e não grava e avisa o usuário que esse horário já está reservado para outra pessoa.

O semafaro você pode fazer por arquivo mesmo, segue abaixo um exemplo de funcao de semafaro que uso a muitos anos e com sucesso

 

Function u_Teste()

Local nSmf

While .t. 

  If !MsgYesNo("Deseja continuar o teste")

    Exit

  EndIf

  nHSmf := AbreSem()

  MsgStop("vou gravar")

  FechaSem(nHSmf)

  MsgStop("semafaro liberado")

EndDo

 

Return

 

Static Function AbreSem(cFile)

Local nHSem

If cFile == nil

  cFile := "semafaro.smf"

EndIf

While (nHSem:=FCreate(cFile))==-1

    fErase(cFile)

    Inkey(.1)

EndDo

Return nHSem

 

Static Function FechaSem(nHSem,cFile)

If cFile == nil

  cFile := "semafaro.smf"

EndIf

FClose(nHSem)

FErase(cFile)

Return

  

[sunset]

Crie um campo no seu banco para controle, quando abrir para edição sinaliza que esta sendo editado e quando finalizar a edição desmarca, no sql voce não vai mais ter o poder de travar o registro, tem que criar um controle para isso.

[emotta]

2 horas atrás, sunset disse:

Crie um campo no seu banco para controle, quando abrir para edição sinaliza que esta sendo editado e quando finalizar a edição desmarca, no sql voce não vai mais ter o poder de travar o registro, tem que criar um controle para isso.

 

Não aconselho a fazer isso pois a longo prazo vai fatalmente acabar resultando em registros marcados como "travados" mas que na realidade não estão pois ocorreu algum crash antes de retirar o flag de travado.

O ideal é fazer o controle fora da tabela.

[sunset]

Uso assim, a uns 12 anos, e sim há um controle para registros que estão marcados como em USO, então um usuario de nivel superior no sistema, pode desmarcar, mas o usuario comum, não e de fato, quando a rede cai ou algo incomum acontece, esta passivel de acontecer isso mesmo, mas na sua solução acima tambem não aconteceria ?

[emotta]

5 horas atrás, sunset disse:

Uso assim, a uns 12 anos, e sim há um controle para registros que estão marcados como em USO, então um usuario de nivel superior no sistema, pode desmarcar, mas o usuario comum, não e de fato, quando a rede cai ou algo incomum acontece, esta passivel de acontecer isso mesmo, mas na sua solução acima tambem não aconteceria ?

Entendi a sua solução proposta que resolve mas gera esses efeitos colaterais que eu não gosto muito por causa dos efeitos.

Na solução de semafaro o handle é liberado se a instancia cair.

[sunset]

Mas se no meio do laço faltar energia e o arquivo estava criado, qual procedimento na volta ?

[emotta]

5 horas atrás, sunset disse:

Mas se no meio do laço faltar energia e o arquivo estava criado, qual procedimento na volta ?

se a instancia cai o semáforo é liberado, não precisa ter acerto de dados nesse sentido.

Então se a instancia cair após aberto o semáforo e antes de finalizar a transação que posteriormente libera normalmente, apesar do arquivo criado a outra instancia vai conseguir criar o semáforo pra ela.

 

 

[emotta]

Vou tentar detalhar melhor:

Continuando o exemplo do Edu o funcionando seria da seguinte forma:

- Quando o cliente ligar para agendar o horário as 09:00 então se deve criar o semafaro com o seguinte nome "AGENDA.SMF". Esse seria o nome do arquivo do semafaro

- Após o comando ABRESEM se faz uma nova checagem na tabela para ver se o horário está mesmo liberado. Se não tiver mais disponivel o semafaro deve ser fechado (FECHASEM) e informado que o horário foi preenchido para outro

- Se o horário ainda estiver liberado o sistema prossegue com a gravação e após o commit se executa o FECHASEM liberando o semafaro

- Se antes do COMMIT ocorrer algum erro e a instancia cair o semafaro é liberado automaticamente pois ao fechar a aplicação o handle do arquivo é liberado.

O processo desta forma é infalivel pois vc faz um LOCK geral, ou seja, ninguem mais grava até o semafaro ser liberado, e só então checa a disponibilidade do horário. Entre o ABRESEM e o FECHASEM ninguem conseguirá gravar por isso é importante que nesse trecho de código não exista pontos de interrupção como MSGSTOP por exemplo.

Esse conceito de semafaro (LOCK) é muito usado em sistemas multithreads para que a aplicação não gere GPF no acesso a variaveis, pois se duas threads tentarem gravar a mesma variavel ao mesmo tempo é gerado GPF. Quem já mexeu com threads no xHarbour sabe do que estou falando, em Harbour não existem esses GPFs pq a própria linguagem faz o lock pra vc (alem de outros controles).

*OBS: os semafaros em multithreads não são em arquivos, é feito de outra forma, eu apenas quis exemplificar o conceito.

[sunset]

Então estou com uma tela de pedidos aberta em 30 maquinas, e 10 usuarios estão incluindo pedidos, ate ai tudo bem APPEND em tudo sem problemas, mas 20 deles estão alterando pedidos, e dentro desses 20 pedidos tem 2 vendedores tentando abrir o mesmo pedido, 1 consegue e o outro não, OK, então temos os restante dos 18 vendedores alterando pedidos o SEMAFARO e criado para cada pedido ? ou vou travar o banco geral, ate um vendedor liberar o pedido ?

[emotta]

Não vai travar nada pra consulta 

Na gravação é feito um por vez, pense em quanto tempo demora desde o append até o commit, vms imaginar q demora 1 décimo de segundo. Neste caso os 18 que estão consultando o farão sem problemas, lembre-se o Lock é só pra gravação, e os outros dois q estão gravando um vai esperar 1 décimo de segundo e o outro vai esperar 2 décimos de segundo ou melhor um piscar de olhos .

Lembrando que o Lock a que me refiro é a técnica de semáforo que expus acima. 

 

 

 

 

 

[emotta]

Outro detalhe é que o seu exemplo acima é totalmente diferente da necessidade do início do post.

No seu exemplo é só usar o Lock de registro da linguagem que é mais eficiente.

O semáforo que me refiro serve muito bem, e sem falhas de gravação, para a situação de checagem se ainda está disponível após a confirmação e antes da gravação.

 

Só uma observação, tenho um sistema de processamento em fila usando essa técnica de semáforo um pouco modificada para 200 clientes com acesso simultâneo e funcionando sem QQ problema, inclusive qdo o sistema cai por falha de conexão com o banco ele retoma o processo sem intervenção manual e ajuste de base.

Vai por mim, funciona e bem.