Muitas pessoas que tentaram configurar a replicação nativa no Firebird (disponível no vanilla Firebird 4 e HQbird v2.5, 3.0, 4.0) se depararam com o problema inesperado – ausência de chave primária ou única para as tabelas que desejam replicar.
Apesar do fato de que ter restrição de chave primária para a tabela é o requisito básico da teoria relacional, vimos muitos bancos de dados onde as tabelas a serem replicadas não tinham chaves primárias ou únicas.
Normalmente os motivos da ausência da chave primária são bem simples: desenvolvedores esqueceram de criar a chave primária ou consideraram a tabela criada como “temporária”, mas ela ficou no esquema, passou a fazer parte da lógica de negócio, etc.
Poucas pessoas também acreditaram erroneamente que a chave primária pode ser substituída por uma combinação de restrição CHECK e/ou trigger Before Insert com “Select…. Where Exists” para verificar a existência da mesma chave. Isso não é verdade, tal esquema não dá garantia de unicidade do valor.
A melhor maneira de resolver o problema descrito é criar uma chave primária para o(s) campo(s) existente(s) que identifica(m) exclusivamente cada registro na tabela. No entanto, pode ser uma tarefa não trivial e demorada, especialmente se o banco de dados for criado por um fornecedor terceirizado ou se tiver uma estrutura complexa.
A alternativa poderia ser a criação de chave primária artificial: ou seja, coluna com valor preenchido automaticamente, com sequência associada (gerador) e gatilho. É necessário criar esses objetos, preencher os valores dos registros existentes, criar a chave primária e, então, criar valores únicos para esse campo a cada novo registro.
Para este propósito, criamos as seguintes instruções e modelos.
1) Precisamos encontrar todas as tabelas sem chaves primárias ou exclusivas. Use o seguinte SQL: