1-Localizar um produto via SELECT;
2-Bloquear o registro já que não posso bloquear a tabela porque estará aberta compartilhada;
3-Fazer a alteração do conteúdo do campo;
4-Liberar a tabela
Esqueça estilo DBF.
Em servidor SQL, NÃO existem dois terminais alterando ao mesmo tempo.
O servidor vai processar os comandos de um terminal por vez.
Atualizar um campo?
UPDATE TABELA SET CAMPO=VALOR WHERE CODIGO=10
Já pesquisou e atualizou.
No momento da atualização, o servidor vai estar processando ESTE comando DESTE terminal.
E aà pergunto: travar pra que?
Imagine um sistema utilizado pelo Brasil inteiro.
Vai bloquear um registro e impedir o Brasil inteiro de atualizar até que o usuário termine?
Se tem dois usuários alterando um cadastro, paciência, o último que gravar é o que fica.
Se um usuário alterar as 4:00 horas e o outro alterar as 05:00 horas, não é o das 05:00 horas que fica?
Porque precisa ser diferente se a diferença de tempo for um milésimo de segundo?
Mesmo em DBF, deveria ser assim.
RecLock()
SKIP 0
REPLACE estoque WITH estoque + 1
SKIP 0
RecUnlock()
Pra que esses SKIP 0 aparentemente inúteis?
Ué... se o registro estava bloqueado, significa que só podiam estar alterando/atualizando.
Se estavam alterando/atualizando, o conteúdo modificou.
Se o conteúdo modificou, um SKIP 0 vai atualizar o cache local.
Após o replace, um SKIP 0 vai garantir que o conteúdo foi salvo.
E uma vez salvo, pode ser liberado pra acesso por outro terminal.
Não precisa ser assim:
RecLock()
@ GET
@ GET
READ
REPLACE
RecUnlock()
Em SQL, um terminal está alterando e o outro exclui:
UPDATE tabela SET CAMPO=CONTEUDO WHERE CODIGO=1
Se o código não existe mais, não vai ser atualizado.
Nenhum erro no aplicativo.
Ah... mas se está alterando não era pra deixar excluir....
Se um usuário altera as 04:00, e o outro exclui as 05:00, não é pra excluir?
Se um usuário exclui as 04:00 horas, o outro consegue alterar as 05:00 horas?
Então... mesma coisa se forem milésimos de segundo de diferença....
Em DBF: antes de atualizar, outro SEEK, igual o SQL faz, e pronto, avisa o usuário que não existe mais.
Dá pra aprender com SQL, e ver que em DBF acostumamos errado.