No artigo de hoje vou explicar o motivo de não usarmos INSERT, UPDATE e DELETE diretamente nas tabelas do Protheus.
Imagina o seguinte cenário, você tem um supermercado, que tem várias regras e vários departamentos. Ai você avisa o gerente do estabelecimento, que tem o Zézinho, e esse rapaz pode fazer o que quiser dentro do mercado sem supervisão.
Então o Zézinho entra no mercado, e se ele quiser tirar produtos das gôndolas (operação DELETE) ele faz. Se ele quiser alterar produtos de uma locação para outra (operação UPDATE) ele faz. Se ele quiser colocar mais produtos do que a prateleira suporta (operação INSERT) ele faz. E tudo isso sem supervisão nenhuma.
Vai ter um momento, em que o pessoal do estoque vai começar a falar que existem falhas no Kardex, assim como pessoal do faturamento, falando que consta produtos para vender, mas ninguém encontra, etc.
Para piorar a situação, o Zézinho vai e coloca por exemplo, cigarros e bebidas no corredor de brinquedos infantis (faz uma operação sem nenhuma integridade de dados). E começam a chegar reclamações de tudo que é lado dos seus clientes.
Pois bem jovens, para contextualizar todo o cenário acima, imagine que o mercado é o ERP e o Zézinho é para quem você deu permissão de executar comandos direto no SQL, seja um estagiário ou uma pessoa que não conheça muito de Banco de Dados.
Toda a estrutura do ERP é feita com validações internas, gatilhos, inicializações, etc… Por isso que, no caso do Protheus, a forma de manipular registros, o ideal é que seja via ExecAuto, e somente quando não é possível (ou quando é tabelas customizadas) que podemos realizar a manipulação com RecLock.
Se simplesmente fizermos tudo via SQL / APSDU, não iremos garantir a integridade dos dados, erros estranhos irão ocorrer na base (como mensagens de falha, queda de serviço, dbaccess podendo apresentar travamentos, etc).
Resumidamente, se você usa o Protheus, opte sempre por ExecAuto e em segundo caso RecLock.
Bom pessoal, por hoje é só.
Abraços e até a próxima.
Olá, Dan.
Os ORMs avançados que existem hoje em dia, como o Spring Boot e o SQLAlchemy, não evitam esse tipo de problema? Eles basicamente fazem o que o Reclock faz…
Pelo que eu entendi, esse cenário é válido quando estamos fazendo iterações diretamente com o banco, sem usar nenhuma ferramenta para segurança de interações com o banco. Está certo?
Porquê os ORMs de hoje em dia fazem toda a tratativa de commits, rollbacks, travar as tabelas p/ evitar duplicidades e garantir a integridade dos dados, e etc. Assim como o RecLock faz…
Só o que eles não vão fazer é gerar os registros de R_E_C_N_O_ e R_E_C_D_E_L automaticamente, e ai essa regra precisa ser desenvolvida.
Ou nada a ver?
Bom dia Raul, tudo joia?
Primeiramente obrigado pelo comentário e pela ótima pergunta.
Na verdade, funcionaria em partes, na parte técnica do banco, você dar o INSERT ou o DELETE com um controle de transações, funcionaria muito bem (conforme você mencionou, talvez apenas adaptando para gerar R_E_C_N_O_ ou R_E_C_D_E_L_).
Porém o problema começa na parte de relacionamentos das tabelas, em uma estrutura relacional comum, você poderia criar Foreign Keys, por exemplo, no pedido de venda, teria uma FK apontando para o cadastro de clientes.
Ai ao manipular um pedido ou um cliente, as chaves estrangeiras seriam validadas (por exemplo, incluir um pedido onde o cliente não exista ou excluir um cliente que tenha pedidos de venda vinculados, o próprio banco de dados iria acusar problemas).
No caso do ERP Protheus, a maioria dos relacionamentos esta cadastrado em uma tabela (a SX9), e não são todos relacionamentos. Então se você fosse dar um INSERT INTO por exemplo, no pedido de venda (SC5), você teria que “manualmente validar as FKs”, do contrário, você pode simplesmente colocar uma informação que não existe.
Se quiser testar, vá numa base de testes, e faça a seguinte operação:
UPDATE SC6010 SET C6_PRODUTO = ‘XXXX’ WHERE [coloque aqui algum filtro só para não demorar muito a query]
Irá perceber que ele vai atualizar todos os produtos de todos os pedidos de venda para o código XXXX e não validar se esse produto existe ou não na SB1.
Para poder sanar parte disso, você pode ativar a Integridade Referencial das tabelas no Configurador, e ai sim, o sistema irá criar as FKs, mas como existem tabelas que podem não ter o relacionamento declarado na SX9, ainda pode haver uma ou outra falha.
Por isso o ideal é que, para o ERP Protheus, não seja manipulado direto informações no banco de dados, e se forem, o analista se atentar muito bem a informação para não afetar a integridade dos dados da base.
Um grande abraço.