Artigo "Novidades do Firebird 2.5": Migrando de versões anteriores

Conforme citado na introdução, a compatibilidade é levada a sério no Firebird. Infelizmente, porém, às vezes é preciso fazer mudanças que causam certas dificuldades de migração. Antes da versão 2.1 o Firebird tinha importantes bugs referentes a implementação de character sets multibyte herdados do InterBase. Um destes character sets é o UNICODE_FSS, que é usado pelas tabelas de sistema RDB$. O Firebird não convertia, do character set cliente para o UNICODE_FSS, nomes, strings e código fonte de objetos durante a execução de comandos DDL e simplesmente gravava os dados, que do ponto de vista do UNICODE_FSS eram inválidos. A partir da versão 2.1 esta conversão passou a ser feita, embora ainda fosse possível a criação de objetos inválidos usando o character set NONE. Para corrigir os objetos gravados de forma incorreta, foi disponibilizado um script que deveria ser rodado após o restore na versão 2.1.

A partir da versão 2.5 o Firebird passou a recusar dados e metadados inválidos com o character set UNICODE_FSS. Isto significaria que qualquer banco de dados de versões anteriores que tivesse problemas de character set não poderia ser restaurado na nova versão. Diante dessa situação, foram acrescentadas duas opções ao gbak, para serem usadas durante o processo de restauração e corrigir este tipo de problema.

A opção -FIX_FSS_METADATA seguida do nome de um character set é usada para informar em que character set foram criados os objetos de banco de dados presentes no backup. Durante a restauração os metadados são convertidos deste character set para o UNICODE_FSS e gravados corretamente.

A outra opção, -FIX_FSS_DATA seguida do nome de um character set, deve ser usada apenas em bancos de dados que tenham tabelas de usuários criadas usando o character set UNICODE_FSS. Esta opção realiza a conversão dos dados da mesma forma que -FIX_FSS_METADATA realiza a conversão dos metadados.

O uso destas opções só é necessário caso o banco possua metadados e dados com caracteres fora do padrão ASCII, como caracteres acentuados, por exemplo. É recomendado que se tente inicialmente fazer a restauração sem usar estas opções. Se o processo falhar por estes problemas, será mostrada uma mensagem de erro recomendando o uso. Para usar o character set correto nestas opções, o usuário precisa ter um conhecimento mínimo sobre character sets (ou páginas de códigos de caracteres) e dos sistemas operacionais usados pelas aplicações cliente. Por exemplo, aplicações que executavam comandos DDL pelo Windows (configurado para Português/Brasil) devem usar WIN1252. Já no Linux a maioria das distribuições atuais trabalha com UTF-8, que é compatível com UNICODE_FSS e não deveria causar problemas.

Estas opções podem não resolver os problemas caso o banco de dados tenha dados ou metadados gravados de forma incorreta usando diferentes character sets. Neste caso será necessário corrigir os problemas com o auxílio dos scripts de migração usando a versão 2.1.

Após a migração do banco de dados, o desenvolvedor precisa se certificar que seus aplicativos conectam-se ao banco usando o client character set correto. O uso do character set NONE (padrão) ou de um character set incorreto podem causar erros de “malformed string” e “transliteration exception”.