No post anterior verificamos que a validação de CRC é realizada pelo Progress em tempo de execução para garantir que um determinado r-code seja compatível com o esquema (estrutura) do banco de dados que o programa irá acessar.
Cada tabela e índice existente em um banco de dados Progress possui um valor de CRC, que é calculado a partir das definições armazenadas no meta-schema (dicionário de dados) do banco de dados. As informações sobre as tabelas, colunas e índices existentes em um banco de dados Progress são armazenadas nas tabelas de sistema _File, _Field, _Index e _Index-Field.
Segue uma lista de quais informações do meta-schema causam uma alteração de CRC quando alteradas. Esta lista pode ser encontrada também no manual OpenEdge Deployment: Managing 4GL Applications, do OpenEdge 10.1A.
Tabela _File: lista das tabelas existentes em cada banco de dados
_File-Name
_DB-lang
Tabela _Field: lista das colunas existentes em cada tabela no banco
_Field-Name
_Data-Type
_dtype
_sys-field
_field-rpos
_Decimals
_Order
_Extent
_Fld-stdtype
_Fld-stlen
_Fld-stoff
_Fld-case
Tabela _Index: lista dos índices existentes em cada banco de dados
_Index-Name
_Unique
_num-comp
Tabela _Index-Field: lista das colunas que fazem parte de cada índice
(_Field-Name)1
_Ascending
_Abbreviate
_Unsorted
1 - O valor _Field-Name não existe fisicamente na tabela _Index-Field. Este valor é recuperado da tabela _Field para a coluna correspondente.
Se alguma das informações listadas acima for alterada para qualquer tabela, coluna ou índice, o CRC do objeto será alterado também. Todos os programas (r-codes) que acessam esta tabela / índice precisarão ser compilados novamente para incorporar a nova estrutura do banco de dados.
Existe ainda um outro motivo que causa alteração do CRC dos objetos do banco de dados: aplicação de segurança com os comandos PROUTIL DBAUTHKEY e PROUTIL RCODEKEY. O Eloi está escrevendo uma série de posts sobre segurança no banco de dados, e estes dois comandos serão abordados nos próximos posts da série.