Dicas Técnicas BufaloInfo

ADO.NET : Testando null em um campo ValueType no DataSet

Variáveis do tipo ValueType no .NET não podem receber valores nulos. Entre elas estão incluidas variáveis numéricas e datetime.

Porém é natural que o banco de dados possua campos numéricos e datetime que aceitem nulo. Neste caso o dataset marcará os campos como aceitando DBNull.

O nulo do banco é um tipo especial no .NET, o tipo DBNull, que pode ser recuperado através de DBNull.Value

O problema é que você não pode comparar o campo do dataset com null (C#) com Nothing (VB.NET), usar a função IsNothing (VB.NET) ou usar a função IsDBNull, nada disso irá funcionar, pois dentro do get da propriedade tipada ocorre um erro pelo fato do valueType ter valor nulo.

Para resolver este problema, quando um campo do dataset tem a opção definida para aceitar DBNull, o dataset tipado cria uma propriedade para testar o nulo neste campo.

Por exemplo, se o campo se chama Data, é criada uma propriedade chamada isDataNull, que deve ser usada para testar se o campo data é nulo antes de ser feito um acesso direto ao campo data.

Por exemplo :

dim l as linharegistro
....

if l.isdatanull then
...

end if

C#

linharegistro l;

...

if (l.isDataNull)
{
....
}

ADO.NET : Editando Schemas de dataSets no VS 2005 (e gerando RSS)

No artigo que encontra-se em http://www.bufaloinfo.com.br/artigos/artigo0701.asp mostrei os detalhes de como produzir RSS facilmente utilizando um dataSet no VS 2003.

O problema é que o editor de DataSets do VS 2005 deixou de ser tão flexivel, não tendo os mesmos recursos de edição de Schema que o editor do VS 2003.

O segredo está no fato de que os editores na verdade foram separados. O editor de dataSets possui apenas os recursos para editar dataSets, porém nada nos impede de abrir o mesmo XSD do dataset no editor de schemas XSD.

Para isso basta clicar com o botão direito no dataSet (pelo solution explorer), utilizar a instrução Open With e escolher o XML Schema Editor. Desta forma poderemos fazer tudo o que faziamos pelo dataSet Editor do 2003, chegando ao mesmo resultado.

ADO.NET : Resolvendo concorrência de dados

O .NET tipicamente faz a manipulação de dados de forma desconectada. Ou seja, um conjunto de dados é levado para a máquina do usuário, manipulado e depois gravado na base de dados.

A manipulação de dados de forma desconectada, porém, causa um volume maior de problemas de concorrência de dados. Ou seja : Dois usuários tentam alterar a informação ao mesmo tempo. Na verdade os problemas de concorrência deixam de se referir a "ao mesmo tempo" : No momento em que um usuário vai gravar, alguém alterou os dados antes, entre o tempo em que ele leu e o tempo em que ele está gravando.

O Framework .NET consegue perfeitamente identificar um problema quando este conflito acontece e avisa ao usuário que ocorreu um erro de concorrência de dados. Neste caso a aplicação precisa estar pronta para fazer o devido tratamento deste erro.

Neste caso o usuário tem em mãos uma informação que não é mais a informação atual no servidor de dados. A aplicação então deverá obter para o usuário a informação mais atual contida no banco de dados.

O que ocorre em seguida pode depender muito da lógica da aplicação. Porém a aplicação pode permitir que o usuário compare a informação que ele alterou com a informação que está no banco de dados e, afinal, decida qual ele deseja manter.

Veja como ficariam alguns trechos da aplicação :

Dim cmd As New SqlClient.SqlCommand

cmd.CommandText = "Select * from tabela where id=@id"
cmd.Parameters.AddWithValue("@id", id)

Até este ponto a aplicação se preparou para ir ao servidor e trazer as informações atuais sobre um determinado registro

Dim dt As New DataTable
dt.Load(cmd.ExecuteReader)

Essas informações são então carregadas em uma nova dataTable

minhatabela.Merge(dt, True)

É realizada a mesclagem da nova dataTable com a dataTable existente com o usuário. Neste ponto está o segredo : True significa manter as alterações do usuário. Então os dados vindos do servidor serão guardados na dataTable como originalValue, o que significa que na próxima gravação o usuário vai sobrepor a versão do servidor.

False, por outro lado, sobrepõe a versão do usuário com a versão do servidor.

Neste exemplo estamos vendo o caso individual de um registro, mas o dataAdapter também possui opções para realizar esta tarefa para uma quantidade maior de registros.

ADO.NET : Camadas com TableAdapter - Interceptando Fill e Update

Neste artigo : http://www.microsoft.com/brasil/msdn/tecnologias/adonet/camadaDados.mspx#ERF expliquei bastante sobre uma técnica bem interessante de acesso a dados. Porém deixei escapar uma informação : E se, para implementar uma regra de negócio, você precisar alterar os métodos Fill e Update seguindo o mesmo molde de partial classes que explico no artigo acima ?

Existe um pequeno truque meio implicito para isso : Quando selecionamos o método criado no tableAdapter (dentro da edição do dataset) e abrimos a janela de propriedades, encontramos uma propriedade modifier para o método Fill e para o método getData, mas não uma opção modifier para o método update, o que poderia nos levar a uma primeira conclusão de que o update acabaria sempre como publico.

Mas se o update acabar sempre como público, teríamos problemas ao implementar nossas regras de negócio. Então como resolver ?

Simples, um truque que passa despercebido : Se o modifier dos métodos fill e getdata for colocado como private, o método update também será colocado como private. Isso nos permite criar nossos próprios métodos para fazer o fill e o update, deixando em aberto a possibilidade de implementação de regras de negócio futuras.

ADO.NET : Retornando o Identity em um Insert do TableAdapter

As atualizações feitas pelo tableAdapter na base de dados já prevêem o retorno de valores identity para uma dataTable que esteja sendo atualizada.

Mas notem : Para uma dataTable que esteja sendo atualizada.

Na Web o uso de DataTables está cada vez mais raro e eventualmente precisaremos que um método insert selecionado em um objectDataSource retorne o identity de um elemento inserido.

Então vamos ver como resolver isso. Estamos falando de utilizar tableAdapters e objectDataSource, você pode ver mais detalhes em http://www.bufaloinfo.com.br/artigos/artigo26062006.asp

O insert padrão do tableAdapter não funciona para isso, pois devolve o número de registros afetados e não o identity. Então depois de criado o TableAdapter precisaremos fazer um Add Query para adicionar um novo insert.

O Wizard nos pergunta se vamos usar SQL, vamos, nos pergunta o tipo de query, insert, e finalmente nos mostra o insert padrão. Você observará que por padrão ele faz um select nos dados inseridos logo após o insert.

O problema é que se seguirmos adiante com o wizard para um insert, ele vai continuar nos devolvendo apenas as rowsAffected. Então para resolver isso fazemos um copy na instrução insert, fazemos um back e selecionamos a opção "select wich return a sigle value".

Colamos então a instrução insert (e o select que a acompanha) na janela do SQL, com pequenas mudanças :

INSERT INTO [dbo].[testeValores] ([valor]) VALUES (@valor);
SELECT SCOPE_IDENTITY()

Damos nome ao nosso método, "Inserir" e não nos preocuparemos com o fato de ele acusar um erro na geração do método.

Porém ao tentarmos configura-lo em uma página web teremos problemas, pois o objectDataSource não irá compreender este método como um insert. Para resolver isso podemos adicionar a seguinte classe em nosso projeto de negócios :

Namespace dsDadosTableAdapters

Public Class testeValoresTableAdapter

<System.ComponentModel.DataObjectMethodAttribute(System.ComponentModel.DataObjectMethodType.Insert, True)> _
Public Function Inserir2(ByVal valor As Integer) As Integer
Return (Inserir(valor))
End Function

End Class
End Namespace

Assim sendo o inserir2 utiliza nosso inserir e contém uma marca como sendo método de insert, nosso inserir pode ficar privado, explicações a mais sobre isso estão no artigo citado acima.

Por fim, para recuperar o Identity retornado utilizamos o evento Inserted do objectDataSource, algo como :

label1.text=e.AffectedRows

ADO.NET : Truques com TableAdapter e ObjectDataSource

O TableAdapter do ADO.NET foi feito para encaixar-se quase perfeitamente ao ObjectDataSource. Quase.

Por default o TableAdapter utiliza a opção "Optimistic Concurrency". Isso é comum em ambiente windows, mas não é comum no ambiente web. Mas é simples resolver : Na tela de definição da query clica-se em Advanced e desmarca-se a opção "Optimistic Concurrency".

Pronto. O ObjectDataSource reconhece o TableAdapter e os métodos de leitura e gravação do TableAdapter, o que é ótimo.

Porém o método de atualização do TableAdapter (Update) é criado recebendo duas vezes a chave da tabela como parâmetro. Teoricamente isso é feito para uma possível atualização do valor da chave primária (valor antigo/valor novo), mas na prática isso raramente é utilizado.

O resultado disso é que a GridView e outros objetos não se encaixam com perfeição neste trabalho, pois não transmitem a chave duas vezes.

Para resolver esse problema, devemos criar uma query de atualização separada no TableAdapter. Basta clicarmos com o botão direito no TableAdapter e selecionarmos Add Query. Selecionamos o tipo da query como Update e o TableAdapter nos traz a instrução de update montada, devemos então ter apenas um cuidado : Trocamos o nome do parâmetro de @original_<campo> (@original_productid, por exemplo) simplesmente pelo nome do campo (@productId, por exemplo).

Como ultimo ajuste, altera-se a propriedade OldValuesParameterFormatString do ObjectDataSource. Normalmente esta propriedade contém Original_{0}, vamos altera-la para apenas {0} e desta forma os nomes de parâmetros vão bater com os nomes esperados pelo tableAdapter.

Com estes ajustes simples, fazemos o acesso em camadas (o TableAdapter como objeto de acesso a dados) sem necessidade de codificar.

ADO.NET : Personalizando os seus tableAdapters

Os tableAdapters do .NET 2.0 são uma excelente ferramenta para acesso a dados no .NET 2, permitindo a criação de camadas de dados - e em alguns casos camadas de negócio também - visualmente.

Essa ferramenta fica ainda melhor com esse truque : Utilizando o recurso das Partial Classes, podemos personalizar o tableAdapter, inserindo nossos próprios métodos e funções neste componente.

Basta declarar uma classe com o mesmo nome que o TableAdapter e a palavra chave Partial . A classe deve ser declarada como estando no mesmo nameSpace que o TableAdapter.

Veja um exemplo :

Namespace NorthwindDataSetTableAdapters
Partial Public Class CustomersTableAdapter

Public Sub hello()

End Sub
End Class
End Namespace

Neste exemplo a sub Hello irá aparecer junto aos demais métodos do TableAdapter, irá fazer parte da classe.

Repare também no seguinte : é possível alterar os modifiers dos métodos do tableAdapter, tornando-os private. Então nos casos mais complexos pode-se ocultar os métodos de acesso direto e criar os nossos próprios métodos, sendo que internamente nossos métodos podem implementar regras de negócio e chamar os métodos private de acesso aos dados.

ADO.NET : Marcando classes como origens de dados

Quando utilizamos o ObjectDataSource, precisamos escolher a classe e o método que utilizaremos como origem de dados. O ObjectDataSource já lista algumas classes e métodos, mas não todos, devido a opção "Show only data components".

Mas como ele identifica os data components ?

É para este tipo de tarefa que temos os atributos de código. O ObjectDataSource utiliza um atributo de código especifico para identificar os componentes que são origens de dados.

Então, se marcarmos a nossa classe com este mesmo atributo, nosso componente também aparecerá no wizard quando a opção "Show only data components" estiver marcada. Isso é bem útil, pois do contrário teríamos que navegar em uma quantidade muito grande de classes.

O atributo em questão chama-se DataObject e fica localizado no namespace System.ComponentModel. Veja :

Imports System.ComponentModel
<DataObject()> Public Class Funcionario

Também é possível marcarmos os métodos, indicando a finalidade de cada um :

<DataObjectMethod(DataObjectMethodType.Select)> Public function Calcular() as DataTable

ADO.NET : Filtrando Nulls em uma dataTable

Uma novidade das dataTables/views no .NET 2.0 é a possibilidade de utilizarmos a função ISNULL para filtrar registros que contenham valores nulos em seus campos.

A função ISNULL funciona de forma semelhante ao ISNULL do SQL Server : você informa um campo e um valor. Se o campo estiver preenchido, o valor do campo é retornado, se estiver null, o outro valor é retornado.

Veja um pequeno exemplo :

DataView Dv = new DataView(MyDataTable);
Dv.RowFilter = "ISNULL(Amount,-9999)=-9999";

Utilizamos o rowFilter da dataview, exatamente como na versão 1.1. Neste exemplo estamos testando o campo Amount. A dataview neste exemplo vai ficar exatamente com os registros nos quais Amount for nulo.

ADO.NET : Obtendo a chave como resposta em um INSERT do TableAdapter

Os TableAdapters permitem a criação de querys personalizadas com extrema facilidade e implementam para nós um método para executar estas querys e nos dar o resultado.

Neste caso, quando digo query me refiro também a instruções de Update/Insert/Delete .

No caso de criarmos uma query de Insert, frequentemente desejaremos a devolução de uma chave. Como fazer para que a query de insert devolva a chave auto-numeração do banco ?

Simples: Na tela em que o tableAdapter nos pergunta o tipo de query, ao invés de selecionarmos o tipo INSERT, vamos selecionar o tipo "SELECT com devolução de um único valor" (é claro que isso aparece em inglês).

Na query, colocamos o seguinte :

INSERT INTO TABELA (...) VALUES (...) ;
SELECT @@IDENTITY

Com isso estamos, logo após o select, recuperando o valor da chave. O método gerado pelo TableAdapter irá nos devolver este valor.