A partir do DBAccess Build 20220303 – Build Version 22.1.1.x – foi implementada uma forma de usar o tipo de campo "unique identifier" ou "uuid" , para os bancos de dados MSSQL, ORACLE e Postgres. O objetivo desse tipo de informação é criar um identificador único para uma determinada linha de uma tabela, usando um identificador de 16 bytes (128 bits) nativo do Banco de Dados, para identificar um determinado registro, e ser possivel manter a sua identificação única desde a criação. PAra cada banco de dados, é usado um tipo nativo do banco de dados para armazenar o valor criado: Para MSSQL, é usado o tipo "uniqueidentifier", para Postgres é usado o tipo "uuid", e para ORACLE, é usado RAW(16).
Cada registro inserido na tabela, caso nao seja informado um valor para o campo usado como identificador único, será populado com um valor único obtido pelo SGDB. Para MSSQL, a constraint default do campo usa o valor retornado pela função NEWID() , para Posgtres é usado o valor obtido da função uuid_generate_v4(), e para Oracle, é usado o valor obtido da função SYS_GUID(). Todas as fun;óes mencionadas são funções nativas do SGDB.
A estrutura da tabela no banco de dados vai usar um tipo de dado que consome apenas 16 bytes, e a aplicação AdvPL pode consultar ou mesmo atribuir um valor no campo, usando uma string de 36 caracteres para os bancos MSSQL e Postgres ( string UUID de 32 caracteres hexadecimais, divididos em 5 blocos com eparadores '-' , agrupando 8-4-4-4-12 caracteres nessa ordem), ou uma string de 32 bytes hexadecimais sem separadores para o banco Oracle.
Uso pela aplicação
A idéia de uso deste campo é que cada novo registro criado em uma tabela receba um identificador único, que possa ser lido pela aplicação, e usado como chave estrangeira em outra(s) tabela(s), com um consumo mínimo de armazenamento, e que seja endereçavel pela aplicação para leitura e atribuição. A visibilidade e tratamento do campo na camada de dados do AdvPL como uma string permite a visualização e manipulação do campo, bem como manter o seu valor em caso de uma manutenção, alteração estrutural ou cópia da tabela de/para outros formatos e vice-versa.
Cada tabela criada pelo DBAccess possui o campo de controle interno R_E_C_N_O_, que emula o numero fisico de um registro ISAM. Esse valor, embora seja atribuído uma vez na inserção, este valor não é persistido ou exportado para outros drivers ou formatos de arquivos de dados, e pode ser recriado caso o controle de numeração da tabela seja alterado. ou uma alteração estrutural exija internamente a recriação da tabela, e por usso o valor do R_E_C_N_O_ nao deve ser usado como chave estrangeira.
Referências