Será um mito? Será verdade? O campo R_E_C_N_O_ sofre alterações? Hoje no Globo Rep… quer dizer, no Terminal de Informação.

Uma das coisas que eu ouvia quando entrei na TOTVS há muitos anos atrás, era que o campo de R_E_C_N_O_ não deveria ser usado em customizações, pois ele poderia sofrer alterações, e o que certo era usar DbSeek. Mas será que essa informação está correta? Vamos descobrir hoje.

O que é o R_E_C_N_O_ / RecNo ?

O RecNo é um campo que existe em todas as tabelas nativas do Protheus, sendo que ele é uma Primary Key auto incremental.

Então a cada linha criada no SQL, o Recno irá incrementar em 1.

Simulando o cenário

Para o nosso cenário de testes, iremos usar a tabela SBM, que possui poucos registros. No nosso exemplo, abaixo segue um print de como está a SBM e o campo de RecNo:

Exemplo da tabela antes de manipulações

Excluindo registros e executando Pack

Agora pelo APSDU, iremos abrir a tabela SBM e excluir uns 3 a 4 registros:

Excluindo os registros

Após a exclusão, iremos limpar os itens excluídos com o Pack. Abaixo o print de como ficou a tabela:

Tabela após executar o Pack

Por último iremos pelo Protheus e incluir manualmente uns 2 grupos de produtos. Após a exclusão, vamos ver como ficou no SQL:

Exemplo de Query com tabela que sofreu o Pack e depois teve registros novos

Pelo menos até agora, não teve alteração no campo de Recno.

Como então surgiu essa afirmação do RecNo sofrer alterações?

Bom, eu tenho uma teoria, sabe antigamente quando as mães falavam que não era pra deixar o chinelo virado, pois elas iriam morrer? Hoje nós sabemos que essa história provavelmente foi criada muitos anos atrás, para as crianças aprenderem um pouco de organização e não ficar deixando as coisas jogadas pela casa.

Acho que é o mesmo caso aqui, onde os analistas mais antigos, viram isso em determinada situação e foram falando para os mais novos e acabou se tornando algo falado para prevenir erros em fontes.

Tanto que, eu conheço uma situação que isso pode acontecer, quando há algum Drop Table e Append de informações. Por exemplo, fiz backup da SBM e a droppei, ela foi recriada pelo Protheus, e como é uma tabela autocontida, já inseriu os registros padrão, ai fui e executei um append do backup, olha o resultado:

Exemplo de Tabela que teve um Drop e depois um Append

Então, o campo RecNo, não sofre alteração, mas se existir alguma manutenção na tabela, como o cenário acima de Drop e Append, o sequencial do RecNo irá ser incrementado conforme a quantidade de registros (note que o registro de Legumes era com RecNo 10 e após esse processo, ele ficou com RecNo 14).

E quais são então as boas práticas?

Vimos então jovens, que naturalmente o RecNo não sofre alterações diretas, há não ser que tenha alguma manutenção na tabela.

Portanto, o que eu recomendo é que nas customizações utilizem as chaves da tabela conforme os índices (na SIX), e para posicionar nos registros, utilizem DbSeek.

Após tiverem bastante experiência com tabelas no Protheus e/ou trabalharem com tabelas customizadas pequenas e temporárias, comecem com poucos testes usando DbGoTo e posicionando com o RecNo.

Então resumindo, se você fizer relatórios, consultas, ou até rotinas básicas que não façam gravação levando em conta o campo de Recno, não haverá problema algum se usar o Recno para posicionar ou exibir. Já se você pretende fazer gravações, evite usar o campo Recno, e tente usar as chaves da tabela conforme os índices da SIX.

Bom pessoal, por hoje é só.

Abraços e até a próxima.

Tags: AdvPLProtheus