Pesquisar Dicas:

Obtendo Schemas de base de dados utilizando o ADO.NET

Existem muitas aplicações que precisam obter informações sobre a estrutura de objetos na base de dados, isso é algo bem frequente. Aplicações para geração de código, por exemplo, precisam de amplas informações sobre a estrutura das bases de dados.

O data provider para OLEDB implementa recursos para obtermos a estrutura de bases de dados. Como trata-se de um data provider ligado a inúmeros bancos de dados (através dos providers OLEDB), podemos obter a estrutura de inúmeros tipos de banco de dados diferentes.

Toda essa possibilidade encontra-se no método chamado GetOleDbSchemaTable. Este método recebe 2 parâmetros : Um GUID que identifica o tipo de objeto que desejamos (tabelas, procedures, views, etc..) e um 2o parâmetro que atua como filtro para os dados que serão retornados. Este método devolve uma dataTable, tornando simples a manipulação dos dados no client.

Vamos então montar um pequeno projeto que nos permita acessar e trabalhar com os dados sobre a estrutura do banco, demonstrando desta forma como manipular estes dados, entre outros exemplos úteis.

Vamos inicialmente criar uma Windows Application com um form e colocar dois objetos no form : Uma listBox (lstObjetos) e uma DataGrid (dg).

Vamos preencher a listbox com uma lista dos tipos de objetos que poderemos estar requisitando da base de dados. Mas este preenchimento não será tão simples : Os tipos de objetos não estão em um enum, estão disponíveis na forma de propriedades da classe System.Data.OleDb.OleDbSchemaGuid, cada uma devolvendo o GUID do tipo de objeto correspondente. Precisaremos então utilizar Reflections para podermos preencher a listbox, veja :

Desta forma vinculamos a listbox a um arrayList de objetos Field, que devolvem os campos existentes na classe OleDbSchemaGuid.

Sempre que houver um click na listbox vamos obter os dados referentes a este tipo de objeto e vamos exibir tais dados na dataGrid. A lista de objetos, porém, é genérica. Portanto nem todos os objetos estão disponíveis para todos os tipos de banco, precisaremos tratar isso também. Veja como fica :

Observe a expressão, um pouco mais complexa, utilizada como primeiro parâmetro no método GetOledbSchemaTable. Tendo o objeto FieldInfo, precisamos utilizar o método GetValue deste objeto para obter o valor de uma propriedade. Porém como as propriedades em questão são Shared, a aplicação do GetValue recebe como parâmetro um type, a própria classe OleDbSchemaGuid .

Pronto. Com essa codificação simples já temos acesso a informações de estrutura da base de dados. Agora vamos tornar esta aplicação um pouco mais sofisticada. Vamos adicionar a possibilidade do usuário fazer personalizações no que é exibido (por exemplo, cortando tipos de objetos desnecessários na listbox e colunas desnecessárias na grid) e manter a configuração feita pelo usuário entre as execuções da aplicação.

Vamos começar com a listbox. Além de possibilitar a deleção de itens da listbox precisaremos guardar os itens que foram deletados em um arraylist, o arrayList dos deletados. Poderemos serializar este arraylist para um arquivo em disco e recupera-lo posteriormente, quando a aplicação for novamente aberta. Então vamos ver como isso fica :

Observe que temos então 2 arrayLists : Um arraylist com os elementos exibidos e um arraylist para guardar os elementos deletados. No exemplo acima adicionamos o nome do item deletado no arrayList de deletados (AR) e eliminamos o item deletado do array de itens exibidos. Para isso criei uma sub a parte chamada remover.

Quanto ao uso do CurrencyManager, acima, isso se deve ao fato de que uma listbox, quando vinculada a um arraylist, não se atualiza automaticamente quando o arrayList se atualiza. Esse assunto foi tema de uma dica no site BufaloInfo, veja em http://www.bufaloinfo.com.br/dicas.asp?cod=725

Veja como fica a sub Remover :

Como o arrayList ligado a combo possui objetos FieldInfo foi necessário localizar o objeto FieldInfo correto para poder elimina-lo.

Agora vejamos como fica o processo de serialização e deserialização do arrayList. Este código é especialmente interessante pois esta tarefa pode ser realizada com qualquer objeto que tenha capacidade de serialização - e são muitos.

Veja o código de serialização :

Como trata-se da gravação de um arquivo em disco, tomei o cuidado de verificar se o arquivo existe e, caso exista, deleta-lo.

Com a classe BinaryFormatter (que fica em System.Runtime.Serialization.Formatters.Binary ) fica fácil fazer o processo de serialização e deserialização de um objeto, como pode observar acima. O FileStream, localizado em System.IO, completa o trabalho fazendo a gravação do resultado da serialização em um arquivo em disco.

Veja como fica a deserialização, tão simples quanto :

Observe que após a deserialização já implementei o que desejamos : faço uma varredura no arraylist e a eliminação dos elementos deletados do arraylist principal.

Neste trecho de código utilizei um truque interessante : Em todos os pontos nos quais me refiro ao nome do arquivo utilizei uma chamada a uma propriedade, NomeHash.

O nome do arquivo propriamente é uma montagem que depende do local onde a aplicação estiver. Utilizando uma propriedade, NomeHash, centralizo em um único ponto do código a geração do nome do arquivo. Assim sendo se em algum momento for necessário alterar o código de geração do nome deste arquivo bastará altera-lo em um único local. Veja como fica a propriedade :

Vamos agora permitir que o usuário personalize as colunas na DataTable e mantenha essa personalização através das execuções da aplicação.

Para permitir a deleção de colunas na grid vamos criar um contextMenu. Porém para que possamos saber em que coluna o mouse estava no momento em que o contextMenu for ativado não irei vincula-lo diretamente na propriedade contextMenu da grid, mas sim ativa-lo através do evento mouseUp. Veja como fica :

Observe que guardei na variável pt um objeto point com as coordenadas do click. Desta forma poderemos utilizar este objeto para descobrir qual foi a coluna clicada. Veja como fica o click do menu :

Através do método HitTest podemos obter informações sobre um determinado ponto com relação a datagrid, descobrindo, por exemplo, qual foi a coluna clicada, para remove-la em seguida como é feito no código acima.

Partimos então para o próximo problema : Como manter a escolha das colunas através das execuções da aplicação ?

A melhor forma de fazer isso é guardando o schema do DataSet em um arquivo em disco. Precisaremos então fazer pequenas adaptações na forma de carregar o dataSet : No nosso exemplo anterior, simplesmente adicionavamos a dataTable. Agora precisaremos manter um dataSet único e chegar se a dataTable já existe ou não. Se não existe, simplesmente adicionamos, mas se já existe então precisamos preencher os dados dentro da estrutura da dataTable já existente, fazendo um Merge.

Veja como fica :

Observe no código acima que o Merge faz uso do MissingSchemaAction. Isso porque o usuário pode ter eliminado alguns campos da tabela. Se o Merge não definisse essa opção os campos seriam re-adicionados.

Outra questão interessante é que neste ponto já transformei essa rotina em uma sub LerSchema. Essa sub é chamada do SelectedIndexChanged da listbox. Veja como fica :

Se a tabela não existe no dataSet ou se está sem linhas é chamada a sub LerSchemas, do contrário é porque os dados já haviam sido carregados antes, então a tabela é apenas exibida novamente.

Serializar e deserializar o schema deste dataSet será uma tarefa bem simples, mais que no caso anterior : O dataSet não precisa que utilizemos uma classe de serialização, como antes, ele próprio possui métodos para fazer a serialização do schema.

Serializar :

   59         ds.WriteXmlSchema(NomeSchema)

Deserializar :

   59         If IO.File.Exists(NomeSchema) Then

   60             ds.ReadXmlSchema(NomeSchema)

   61         End If

Propriedade NomeSchema :

  146     Private ReadOnly Property NomeSchema() As String

  147         Get

  148             Return (Application.StartupPath & "\schema.xml")

  149         End Get

  150     End Property

Neste ponto já conseguimos permitir que o usuário personalize a aplicação e que esta personalização seja mantida, o que já torna a aplicação bem interessante.

Mas para que a aplicação fique ainda mais útil torna-se necessário permitir que a aplicação guarde não apenas uma, mas diversas configurações nomeadas. Assim sendo o usuário pode se conectar a diferentes bancos de dados e guardar as configurações de como deseja visualizar cada um.

Vamos começar criando uma classe Configuracao para agregar os dados que cada configuracao deve ter. Uma configuração terá um nome, uma string de conexão e irá também gerar um código que será anexado aos nomes de arquivos que guardarão as características da configuração. Veja como fica :

Criei um construtor recebendo parâmetros, para simplificar a configuração desta classe. Uma propriedade readonly chamada CodigoArquivo, que irá gerar uma pequena string a ser anexada o nome dos arquivos. A função ToString levou um overrides para podermos definir o que desejamos que apareça em uma combo quando esta classe for inserida em uma combo.

Vamos então preparar este formulário que temos para poder lidar com essa classe. Esse formulário irá receber uma instância desta classe como parâmetro quando for aberto (o usuário já terá escolhido a configuração - faremos isso depois) e deverá utilizar as informações contidas nesta classe.

Primeiramente, uma propriedade para controlar o recebimento desta classe :

As propriedades que geram os nomes dos arquivos passarão a utilizar esta propriedade configuração, veja :

Podemos também exibir no título do form o nome da configuração selecionada :

Precisaremos de um botão que permita ao usuário trocar a configuração selecionada. Neste caso o ideal será transformarmos a inicialização do form (deserializações) e a finalização (serializações) em subs que possam ser chamadas de mais de um local. Veja como fica :

Desta forma podemos chamar essas subs do evento Load, closing, do botão e uma chama a outra (ao trocar a configuração, salva-se a anterior).

Vamos então criar um 2o form, que permitirá ao usuário selecionar a configuração desejada ou criar uma nova configuração. A aplicação passará a ser disparada por uma sub main que interligará os dois forms, veja :

No formulário para escolha da configuração, vamos chama-lo de frmConfig, vamos inserir uma combo para listar as configurações existentes, um botão para disparar a criação de uma nova configuração e um botão para dar ok na seleção de uma configuração e seguir adiante.

Teremos mais um arquivo serializado, que conterá a lista de configurações existentes. Precisaremos no load do form fazer a deserialização deste arquivo. Veja como fica :

Quando um item na combo for selecionado, habilitamos o botão ok. Quando o botão Ok for clicado, atribuimos a classe selecionada na variável Configuracao. Veja como fica :

Quando o usuário clicar no botão para adicionar uma nova configuração precisaremos fazer os seguintes passos :

• Perguntar o nome da nova configuração
• Permitir que o usuário monte uma string de conexão
• Criar uma nova instância da classe config, adicionar no arrayList e fazer refresh da combo

Veja como fica :

Observe que neste código utilizei um truque para exibir para o usuário a própria janela de configuração de uma conexão do OLEDB, permitindo desta forma que o usuário crie a string de conexão em um ambiente já familiar a ele. Isso foi exposto em uma dica em http://www.bufaloinfo.com.br/dicas.asp?cod=430

Agora que chegamos neste ponto e a aplicação já está funcionando e guardando configurações diversas do usuário, vamos então inserir na aplicação a capacidade de fazer filtragens das informações exibidas. Vamos criar 2 tipos de filtragem : Uma filtragem simples, aplicada sobre os dados exibidos e uma filtragem relacionada, por exemplo, o usuário desejará ver os campos de uma determinada tabela.

Vamos começar, claro, pela filtragem mais simples. Precisaremos criar um formulário novo através do qual o usuário possa definir a filtragem a ser realizada. Vamos chamar este novo formulário de frmRestricoes.

Muitos objetos deste formulário deverão ser dinâmicos. Ele deverá exibir os campos existentes na DataTable que será filtrada (exibir mesmo campos que tenham sido excluidos pelo usuário) e permitir que o usuário digite, para cada campo, o critério de filtro, ou deixe o campo vazio. Assim sendo deverão ser criados labels e textboxes tantos quantos forem os campos da dataTable sendo filtrada.

Mas isso se complica um pouco mais. As DataTables possuem os campos devolvidos pelo provider OLEDB, fornecendo informações sobre determinados tipos de objetos no banco. O problema é que alguns dos campos em cada DataTable são específicos de determinados data providers e, por isso, não podem ser usados como parte das restrições. As DataTables tem um conjunto de campos genéricos, estes podendo ser usados nas restrições, e um conjunto de campos específicos, que não podem. O número de campos que podem ou não serem utilizados nas restrições variam para cada DataTable.

No endereço http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/oledbschema_rowsets.asp encontrei documentação sobre quantas colunas de cada tipo de DataTable podem ser usadas como critério. Isso acaba sendo algo fixo, veja como codifiquei, para resolver o problema :