7. Estudo de caso com o Firebird 2.1
7.1. Instalação das ferramentas
As ferramentas a serem instaladas são as seguintes:
- o SGBD: [http://www.firebirdsql.org/en/firebird-2-1-5/];
- uma ferramenta de administração: EMS, SQL Manager para InterBase/Firebird Freeware [http://www.sqlmanager.net/fr/products/ibfb/manager/download].
Nos exemplos a seguir, o usuário é sysdba com a senha masterkey.
Vamos iniciar o Firebird e, em seguida, a ferramenta [SQL Manager Lite for Firebird], com a qual administraremos o SGBD.
![]() |
- No [1], iniciamos o Firebird SGBD a partir do Menu Iniciar. Aqui, o SGBD não foi instalado como um serviço do Windows;
- em [2], o serviço é iniciado. Um ícone apareceu no canto inferior direito da tela. Com um clique direito nele, é possível parar o SGBD.
Agora, iniciamos a ferramenta [SQL Manager Lite for Firebird], com a qual administraremos o SGBD e o [3].
![]() |
- no [4], criamos um novo banco de dados;
- no [5], confirmamos;
![]() |
- em [5], fazemos o login como SYSDBA / masterkey;
- em [6], indicamos o local do arquivo que será criado. De fato, o banco de dados será criado em um único arquivo;
- em [7], confirma-se a ordem SQL que será executada;
![]() |
- em [8], o banco de dados foi criado. Agora ele deve ser gravado em [EMS Manager]. As informações estão corretas. Executa-se [OK];
- no [9], conectamo-nos a ela;
- em [10], o [EMS Manager] exibe o banco de dados, que por enquanto está vazio.
Agora vamos conectar um projeto VS 2012 a esse banco de dados.
7.2. Criação do banco de dados a partir das entidades
Começamos duplicando a pasta do projeto [RdvMedecins-SqlServer-01] em [RdvMedecins-Firebird-01] e [1]:
![]() |
- em [2]; em VS 2012, excluímos o projeto [RdvMedecins-SqlServer-01] da solução;
![]() |
- em [3], o projeto foi excluído;
- em [4], adicionamos outro. Este está contido na pasta [RdvMedecins-Firebird-01] que criamos anteriormente;
![]() |
- em [5], o projeto carregado se chama [RdvMedecins-SqlServer-01];
- em [6], alteramos o nome para [RdvMedecins-Firebird-01]
![]() |
- em [7], adiciona-se outro projeto à solução. Esse projeto está na pasta [RdvMedecins-SqlServer-01] do projeto que havíamos excluído da solução anteriormente;
- no [8], o projeto [RdvMedecins-SqlServer-01] foi reintegrado à solução.
O projeto [RdvMedecins-Firebird-01] é idêntico ao projeto [RdvMedecins-SqlServer-01]. Precisamos fazer algumas modificações. No [App.config], vamos alterar a string de conexão e o [DbProviderFactory], que deve ser adaptado a cada SGBD.
<!-- cadeia de conexão com o banco de dados -->
<connectionStrings>
<add name="monContexte" connectionString="User=SYSDBA;Password=masterkey;Database=D:\data\istia-1213\c#\dvp\Entity Framework\databases\firebird\RDVMEDECINS-EF.GDB;DataSource=localhost;
Port=3050;Dialect=3;Charset=NONE;Role=;Connection lifetime=15;Pooling=true;MinPoolSize=0;MaxPoolSize=50;Packet Size=8192;ServerType=0;" providerName="FirebirdSql.Data.FirebirdClient" />
</connectionStrings>
<!-- o provedor de fábrica -->
<system.data>
<DbProviderFactories>
<add name="Firebird Client Data Provider" invariant="FirebirdSql.Data.FirebirdClient" description=".Net Framework Data Provider for Firebird" type="FirebirdSql.Data.FirebirdClient.FirebirdClientFactory, FirebirdSql.Data.FirebirdClient, Version=2.7.7.0, Culture=neutral, PublicKeyToken=3750abcc3150b00c" />
</DbProviderFactories>
</system.data>
- linha 3: o usuário e sua senha, bem como o caminho completo do banco de dados Firebird;
- linhas 8 a 10: o DbProviderFactory. A linha 9 faz referência a um DLL e a um [FirebirdSql.Data.FirebirdClient] que não temos. Ela é obtida com NuGet e [1]:
![]() |
- no [2], na área de pesquisa, digite a palavra-chave firebird;
- em [3], selecione o pacote [Firebird ADO.NET Data Provider]. Trata-se de um conector ADO.NET para o Firebird;
![]() |
- em [4], a nova referência;
- em [5], em [App.config], é preciso inserir a versão correta do DLL. Ela pode ser encontrada nas propriedades do arquivo.
No arquivo [Entites.cs], é preciso adaptar o esquema das tabelas que serão geradas:
[Table("MEDECINS")]
public class Medecin : Personne
{...}
[Table("CLIENTS")]
public class Client : Personne
{...}
[Table("CRENEAUX")]
public class Creneau
{...}
[Table("RVS")]
public class Rv
{...}
Aqui, as tabelas não possuem esquema.
Configuramos a execução do projeto:
![]() |
- em [1], atribuímos outro nome ao assembly que será gerado;
- em [2], definimos também outro namespace padrão;
- em [3], indicamos o programa a ser executado.
Nesta fase, não há erros de compilação. Vamos executar o programa [CreateDB_01]. Recebemos a seguinte exceção:
Lembramos de ter tido o mesmo erro com MySQL, Oracle e PostgreSQL. Isso está relacionado ao tipo do campo Timestamp das entidades. Fazemos a mesma alteração que fizemos nos dois SGBD anteriores. Nas entidades, substituímos as três linhas
[Column("TIMESTAMP")]
[Timestamp]
public byte[] Timestamp { get; set; }
pelas seguintes:
[ConcurrencyCheck]
[Column("VERSIONING")]
public int? Versioning { get; set; }
Portanto, alteramos o tipo da coluna de byte[] para int?. No SGBD, utilizaremos procedimentos armazenados para incrementar esse inteiro em uma unidade sempre que uma linha for inserida ou modificada.
Fazemos a modificação anterior nas quatro entidades e, em seguida, reexecutamos o aplicativo. Recebemos então o seguinte erro:
A linha 1 indica que o banco de dados está em uso. Pelo que me parece, esse não era o caso, e não consegui resolver esse problema.
Não importa. Vamos construir o banco de dados [RDVMEDECINS-EF] manualmente com a ferramenta [EMS Manager for Firebird]. Não descreveremos todas as etapas, mas apenas as mais importantes.
O banco de dados Firebird será o seguinte:
As tabelas
![]() |
- em [1], ID é uma chave primária com o atributo Autoincrement. Ela será gerada automaticamente pelo SGBD;
![]() |
![]() |
![]() |
As diferentes tabelas possuem as chaves primárias e estrangeiras que essas mesmas tabelas tinham nos exemplos anteriores. As chaves estrangeiras possuem o atributo ON, DELETE e CASCADE.
Os geradores
Assim como no Oracle e no PostgreSQL, criamos geradores de números consecutivos. São 5: [1].
![]() |
- [CLIENTS_ID_GEN] será usado para gerar a chave primária da tabela [CLIENTS];
- [MEDECINS_ID_GEN] será usado para gerar a chave primária da tabela [MEDECINS];
- [CRENEAUX_ID_GEN] será utilizado para gerar a chave primária da tabela [CRENEAUX];
- [RVS_ID_GEN] será utilizado para gerar a chave primária da tabela [RVS];
- [VERSIONS_GEN] será utilizado para gerar os valores das colunas [VERSIONING] de todas as tabelas.
Os gatilhos
Um trigger é um procedimento executado pelo SGBD antes ou depois de um evento (inserção, modificação, exclusão) em uma tabela. Temos 8 deles, [1]:
![]() |
Vamos examinar o código DDL do trigger [BI_CLIENTS_ID], que preenche a coluna [ID] da tabela [CLIENTS]:
- linha 2: antes de cada inserção na tabela [CLIENTS];
- linhas 6-7: se a coluna ID for NULL, então atribui-se a ela o próximo valor do gerador de números [CLIENTS_ID_GEN].
Os gatilhos [ BI_CLIENTS_ID, BI_MEDECINS_ID, BI_CRENEAUX_ID, BI_RVS_ID] são todos construídos da mesma maneira.
Vejamos agora o código DDL do gatilho [CLIENTS_VERSION_TRIGGER], que alimenta a coluna [VERSIONING] da tabela [CLIENTS]:
- linhas 1-3: antes de cada operação INSERT ou UPDATE na tabela [CLIENTS];
- linha 6: a coluna ["VERSIONING"] recebe o seguinte valor do gerador de números [VERSIONS_GEN]. Esse gerador alimenta as colunas ["VERSIONING"] das quatro tabelas.
Os gatilhos [MEDECINS_VERSION_TRIGGER, CRENEAUX_VERSION_TRIGGER, RVS_VERSION_TRIGGER] são análogos.
O script de geração das tabelas do banco de dados Firebird [RDVMEDECINS-EF] foi colocado na pasta [RdvMedecins / databases / Firebird]. O leitor poderá carregá-lo e executá-lo para criar suas tabelas.
Feito isso, os diversos programas do projeto podem ser executados. Eles fornecem os mesmos resultados que com o SQL Server, exceto pelo programa [ModifyDetachedEntities], que trava pelo mesmo motivo que travava com o Oracle e o MySQL. O problema é resolvido da mesma maneira. Basta copiar o programa [ModifyDetachedEntities] do projeto [RdvMedecins-Oracle-01] para o projeto [RdvMedecins-Firebird-01].
7.3. Arquitetura multicamadas baseada em EF 5
Voltamos ao nosso estudo de caso descrito no parágrafo 2.
![]() |
Começaremos construindo a camada [DAO] de acesso aos dados. Para isso, duplicamos o projeto de console VS 2012 [RdvMedecins-SqlServer-02] em [RdvMedecins-Firebird-02] [1]:
![]() |
- em [2], excluímos o projeto [RdvMedecins-SqlServer-02];
![]() |
- em [3], adiciona-se um projeto existente à solução. Ele é obtido da pasta [RdvMedecins-Firebird-02] que acaba de ser criada;
- em [4], o novo projeto tem o mesmo nome daquele que foi excluído. Vamos alterar seu nome;
![]() |
- em [5], alteramos o nome do projeto;
- em [6], alteramos algumas de suas propriedades, como, neste caso, o nome do assembly;
- em [7], a pasta [Models] é excluída para ser substituída pela pasta [Models] do projeto [RdvMedecins-Firebird-01]. De fato, os dois projetos compartilham os mesmos modelos.
![]() |
- em [8], as referências atuais do projeto;
- no [9], foi adicionado o conector ADO.NET do Firebird com a ferramenta NuGet.
No arquivo [App.config], substituímos as informações do banco de dados SQL Server pelas do banco de dados Firebird. Elas podem ser encontradas no arquivo [App.config] do projeto [RdvMedecins-Firebird-01]:
<!-- cadeia de conexão com o banco de dados -->
<connectionStrings>
<add name="monContexte" connectionString="User=SYSDBA;Password=masterkey;Database=D:\data\istia-1213\c#\dvp\Entity Framework\databases\firebird\RDVMEDECINS-EF.GDB;DataSource=localhost;
Port=3050;Dialect=3;Charset=NONE;Role=;Connection lifetime=15;Pooling=true;MinPoolSize=0;MaxPoolSize=50;Packet Size=8192;ServerType=0;" providerName="FirebirdSql.Data.FirebirdClient" />
</connectionStrings>
<!-- o provedor de fábrica -->
<system.data>
<DbProviderFactories>
<add name="Firebird Client Data Provider" invariant="FirebirdSql.Data.FirebirdClient" description=".Net Framework Data Provider for Firebird" type="FirebirdSql.Data.FirebirdClient.FirebirdClientFactory, FirebirdSql.Data.FirebirdClient, Version=2.7.7.0, Culture=neutral, PublicKeyToken=3750abcc3150b00c" />
</DbProviderFactories>
</system.data>
Os objetos gerenciados pelo Spring também mudam. Atualmente, temos:
<!-- configuração do Spring -->
<spring>
<context>
<resource uri="config://spring/objects" />
</context>
<objects xmlns="http://www.springframework.net">
<object id="rdvmedecinsDao" type="RdvMedecins.Dao.Dao,RdvMedecins-SqlServer-02" />
</objects>
</spring>
A linha 7 faz referência ao assembly do projeto [RdvMedecins-SqlServer-02]. O assembly agora é [RdvMedecins-Firebird-02].
Feito isso, estamos prontos para executar o teste da camada [DAO]. Antes disso, é preciso preencher a base de dados (programa [Fill] do projeto [RdvMedecins-Firebird-01]). O programa de teste é executado com sucesso.
Criamos a DLL do projeto, da mesma forma que foi feito para o projeto [RdvMedecins-SqlServer-02], e reunimos oconjunto de DLL do projeto em uma pasta [lib] criada em [RdvMedecins-Firebird-02]. Essas serão as referências do projeto web [RdvMedecins-Firebird-03] que virá a seguir.
![]() |
Agora estamos prontos para construir a camada [ASP.NET] do nosso aplicativo:
![]() |
Vamos partir do projeto [RdvMedecins-SqlServer-03]. Duplicamos a pasta desse projeto em [RdvMedecins-Firebird-03] e [1]:
![]() |
- em [2], com o VS 2012 Express para a web, abrimos a solução da pasta [RdvMedecins-Firebird-03];
- em [3], alteramos tanto o nome da solução quanto o nome do projeto;
![]() |
- em [4], as referências atuais do projeto;
- em [5], as eliminamos;
- em [6], para substituí-las por referências ao DLL que acabamos de armazenar na pasta [lib] do projeto [RdvMedecins-Firebird-02].
Resta apenas modificar o arquivo [Web.config]. Substituímos seu conteúdo atual pelo conteúdo do arquivo [App.config] do projeto [RdvMedecins-Firebird-02]. Feito isso, executamos o projeto web. Ele funciona. Não se esqueça de preencher o banco de dados antes de executar o aplicativo web.

























