asfernandes
This blog has a new home: https://asfernandes.github.io

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”.

 

O desenvolvimento do SGBD Firebird foi iniciado em Julho do ano 2000 a partir do código fonte da versão beta do InterBase 6.0, disponibilizado pela Inprise (Borland) sob licença open source. Desde então cinco versões foram lançadas pela sua equipe de desenvolvimento, mostrando uma evolução contínua do produto. O foco deste artigo é mostrar as principais funcionalidades para desenvolvedores adicionadas à versão 2.5, lançada em outubro de 2010, no ano em que o projeto faz seu décimo aniversário. Antes de aprofundar nestes temas, gostaria de mostrar um breve histórico da evolução do Firebird nestes dez anos.

Na versão 1.0 a maior parte do trabalho foi interna, já que o código inicial não tinha documentação e não chegava nem mesmo a compilar. Uma das alterações mais importantes nesta versão foi a correção de um bug de segurança do InterBase, que foi rapidamente identificado quando seu código tornou-se público.

Na versão 1.5 o código fonte foi convertido de C para C++. Algumas novidades que apareceram nesta versão foram variáveis de contexto como CURRENT_USER e CURRENT_ROLE, funções como COALESCE e NULLIF, expressões CASE, o tipo de dados BIGINT, melhorias em alguns comandos DDL (CREATE OR ALTER, RECREATE), o comando EXECUTE STATEMENT, as cláusulas FIRST e SKIP e suporte a savepoints e locks pessimistas.

A versão 2.0 introduziu as tabelas derivadas [1], cursores explícitos, valores default para parâmetros, as funções IIF, CHAR_LENGTH, TRIM, RDB$GET_CONTEXT e RDB$SET_CONTEXT, o operador IS [NOT] DISTINCT, os comandos EXECUTE BLOCK e COMMENT ON, a cláusula RETURNING, índices definidos por expressões, collates (PT_BR e WIN_PTBR) para o Brasil, suporte a Unicode, melhorias de performance relacionadas à nova implementação de índices e diversas mudanças no otimizador, backups físicos e incrementais com o NBackup e suporte a plataformas 64-bit.

A versão 2.1 introduziu dezenas de novas funções internas, triggers de eventos de conexão e transação, tabelas temporárias, collates customizáveis com CREATE COLLATION, queries recursivas com Common Table Expression (CTE) [2], os comandos UPDATE OR INSERT e MERGE, a função agregada LIST, a possibilidade de uso de domains em PSQL, a interoperabilidade entre BLOBs e strings, tabelas de monitoração, o utilitário fbsvcmgr e diversas melhorias implementadas no protocolo de comunicação, melhorando a performance de comunicação cliente/servidor via internet.

Diante de toda essa evolução, é importante ressaltar que toda alteração e nova funcionalidade do Firebird é pensada levando em consideração dois princípios estabelecidos pelo projeto: compatibilidade e padronização SQL. A compatibilidade é sempre levada extremamente a sério, e dificilmente algo que funciona em uma versão deixa de funcionar em outra, respeitando o investimento feito pelos desenvolvedores. Em relação ao padrão SQL, ele é sempre consultado e analisado em detalhes, e quando possível, as implementações são realizadas com base neste padrão.

A versão 2.5, assim como as anteriores, possui diversas novas funcionalidades. Primeiramente, veremos sobre possíveis problemas durante o processo de migração. Em seguida, veremos sobre a nova arquitetura SuperClassic, que permite melhor aproveitamento de recursos e melhor desempenho em máquinas multiprocessadas, e as alterações diretamente relacionadas ao desenvolvimento. Os exemplos presentes nas listagem foram feitos para o ISQL, mas devem funcionar sem problemas em qualquer ferramenta.

Notas

[1] - Tabela derivada (derived table) é o nome dado pelo padrão SQL a uma query usada na claúsula FROM de outra query. Por exemplo: SELECT X.* FROM (SELECT * FROM PESSOA) X. Neste caso, X é uma tabela derivada. Veja mais exemplos no release notes da versão 2.0.

[2] - Common Table Expression (CTE) é similar as tabelas derivadas, mas o nome da tabela é definido no começo da instrução com a cláusula WITH. Exemplo: WITH X AS (SELECT * FROM PESSOA) SELECT * FROM X. Com as CTEs é possível fazer queries hierárquicas (recursivas) usando-se WITH RECURSIVE e UNION ALL. Veja mais exemplos no release notes da versão 2.1.

 

A partir de sexta-feira, dia 20/12/2013, começarei a postar o artigo que escrevi para a revista ClubeDelphi. Esse artigo saiu na edição #125 da revista, em dezembro de 2010.

O artigo será postado em partes, conforme abaixo:

- Introdução
- Migrando de versões anteriores
- A arquitetura SuperClassic
- Character Sets e Collates
- Comandos DDL (Data Definition Language)
- Expressões, literais e funções
- Linguagem PSQL
- Conclusão