Visão Global
Nenhum homem é uma ilha muito menos um servidor. Para o servidor IIS-WEB executar seus serviços ele conta com inúmeros aliados. O mais íntimo é o próprio sistema operacional do servidor que suporta a aplicação IIS.
Sendo assim o serviço WEB faz a parte dele e a que não compete a ele, ele a delega para alguns componentes registrados no sistema que suporta o serviço WEB. O serviço mais básico é o de comunicação, ou seja, o serviço que envia o conteúdo da página web via rede / TCP-IP. O servidor web monta a página e manda o serviço TCP-IP do sistema operacional despachar o pacote.
Outro serviço muito comum nos servidores web é o de banco de dados. Via de regra não colocamos 2 serviços com alta prioridade no mesmo servidor porque esses serviços literalmente pode parar um ao outro solicitando prioridade máxima de processamento. Lembre-se de que quanto mais prioritário é o serviço melhor ele está integrado com o sistema operacional.
Quando uma página asp net acessa uma base de dados ela utiliza uma metodologia que visa ser a mais abrangente e simples possível de maneira que possamos trabalhar com as bases de dados mais heterogêneas praticamente da mesma maneira.
Nessa metodologia o acesso a bases de dados e exibição dos resultados é feita por :
1-Componentes externos a página ASP.NET que trazem os dados da base de dados para os componentes internos ao ASP.NET. São os famosos clients do SQL Server, Oracle, Postrgre, etc. São chamados de 'data access' porque formam uma camada de comunicação entre os servidores SQL e o servidor local. São estes componentes que trazem os dados do servidor e colocam num 'recordset' ( registro de dados ).
2-Os Componentes internos a página ASP.NET que são os datasets, datatables. Esses componentes fazem a interface entre o mundo externo e a página asp net. São tão bem feitos que uma dataset pode conter dezenas de datatables com o relacionamento e tudo mais copiado do próprio sql server. Literalmente trazem o banco de dados para dentro da estrutura de dados da sua página.
A ilustração exibe melhor esses detalhes.
Os componentes externos de acesso a dados são dlls externas ao serviço IIS ASP.NET e antigamente era um grande furo na segurança do servidor pois permite que uma página ASP.NET acesse um recurso externo que o servidor possua. Hoje em dia o serviço de segurança criou uma 'compartimentalização' onde uma página ASP NET só pode acessar os recursos dentro da pasta bin do root do site. Este acesso é apenas de leitura e execução e com isto garante que a aplicação sobreviva aos ataques de hoje.
Contudo sabemos que o poder do usuário é determinado pela liberdade que ele tem de fazer suas tarefas. O problema é que ninguém é perfeito.
Hoje em dia essas 'ameaças' foram mitigadas por medidas de segurança como dlls assinadas que possuem um processo de autenticação que identifica a origem, procedência e autoria do componente com chaves criptográficas de 256 bits iguais às do sistema bancário.
Outro recurso de segurança dos servidores ASP NET é o System.Security. Fundamental. Você consegue imaginar um banco sem um algorítimo de criptografia descente ? Impossível né? E fique sabendo que as principais mudanças do Windows 7 para Windows 8 e o Windows 10 foram nos serviços de segurança. Hoje um browser tem acesso a serviços de criptografia fornecidos pelo próprio sistema operacional.
Na prática o que precisamos para acessar um banco de dados SQL
A primeira coisa a saber é que existe 2 elementos distintos : Um externo chamado de 'Data Provider' e um interno ao ASP NET que são mais de um e cada qual com sua finalidade e utilização.
Elemento 1 : Externo ao ASP NET - Data Provider
São os famosos 'Clients' ou 'data access components'. São componentes externos específicos para acessar um tipo de servidor SQL ( um para MS SQL, outro para Oracle etc.) que nada mais é que um 'adaptador' ( não é o termo correto mas didaticamente é o que melhor representa o objeto ) que faz a interface entre o banco de dados SQL e o ASP NET. Normalmente é um componente ADO ou ODBC que o próprio fabricante produz, para ser exato, uma dll externa ao ASP NET ( mas acessível e registrada no sistema operacional ) e que permite um conjunto de funcionalidades que permitem que o ASP NET se 'comunique' com o banco de dados. Neste elemento temos os detalhes:
1-O componente de acesso a dados em sí: ADO, ODBC seja o que for. Normalmente precisa ser instalado no computador.
2-A cadeia de caracteres mais conhecido como string de conexão informando os parâmetros que serão usados na conexão. Esses parâmetros são:
2.1-Servidor : Pode ser tanto um ip, o nome do servidor na rede local ou uma url de um servidor remoto.
2.2-Banco de dados : É o banco de dados que desejamos obter as informações. Normamente com o banco de dados é definido o SCHEMA que define os usuários do banco de dados.
2.3-Usuário : Usuário que será utilizado para acessar o banco de dados. Esse usuário é previamente cadastrado no banco de dados pelo administrador do banco de dados e as atividades que ele poderá executar no banco de dados serão determinadas pelo SCHEMA dele ( pelo comando grant ) que dá permissão de conexão, select, delete, update entre outros e essas permissões são definidas separadamente e, inicialmente, todas as permissões estão negadas no banco de dados.
2.4-Senha do usuário no banco de dados : É a senha do usuário do banco de dados. Tome cuidado para saber se a conexão é criptografada ou não porque se não for a senha será enviada como um texto comum.
Caso tenha dúvida de como o string de conexão é formado consulte a Internet. Sugiro :
O site linha de código
ou
o site Connection Strings
Note que cada gerenciador de banco de dados tem seu 'jeito' de funcionar e com isto o string de conexão tem que ser adapatado. Por exemplo, se você está usando o Microsoft SQL Server sabe que a autenticação do SQL Server pode ser integrada com a do Windows ou Active Directory e com isso podemos com o mesmo usuário do windows acessar o banco de dados sql sem ter que pedir o login ( apresentação de credenciais ). No string de conexão colocariamos algo parecido com 'Trusted_Connection=Yes;' para indicar esta condição.
Algumas informações de segurança podem ser passadas através do string de conexão como obrigando a usar criptografia SSL (no MySQL SslMode=Required) ou preferindo usar a criptografia SSL mas permitindo a conexão sem SSL (SslMode=Preferred;). Como eu disse, cada 'fabricante' de banco de dados faz o seu padrão independente dos demais. Felizmente com a linguagem SQL a coisa é mais padronizada, sem bem que há diferenças de implementação.
Note que até a versão do SQL que queremos conectar modifica o string de conexão.
Se algum dos parâmetros faltar no string de conexão : servidor, Banco de dados, usuário ou senha não conseguiremos conectar com o banco de dados.
DataProvider ou Fontes de dados
| Data Source | Data Provider |
|---|---|
| Microsoft Acess Database File | .NET Framework Data Provider OLE DB - Microsoft.Jet.OLEDB.4.0 - System.Data.OleDb (*1) |
| Microsoft ODBC Data Sorce(Excel/Office) | .NET Framework Data Provider ODBC - System.Data.Odbc (*4) |
| Microsoft SQL Server | .NET Framework Data Provider for SQL Server - System.Data.SqlClient (*2) |
| Microsoft SQL Server Compact 3.5 | .NET Framework Data Provider for Microsoft SQL Server compact 3.5 |
| Microsoft SQL Server DatabaseFile | .NET Framework Data Provider for Microsoft SQL |
| Oracle Database | .NET Framework Data Provider for Oracle - System.Data.OracleClient (*3) |
O uso desses componentes estão ligados diretamente a versão do servidor de dados :
*1-MS SQL Server 7 ou posterior, Azure ou mais recente.
*2-MS SQL Server 2005 ou anterior. Versões muito antigas dos servidore MS SQL .
*3-Oracle 7.3, 8i, 9i, 10g, 11.
*4-Precisa do Office instalado para funcionar.
Todo data provider tem 3 elementos :
1-Conexão ( connection ): Proporciona a conexão com a fonte de dados.
2-Commando ( command ) : executa uma querie que não retorna dados ( Ex: delete, insert, etc..)
2.1-Emite os comandos para as bases de dados que retornam ou modificam dados.
2.2-Executam Stored Procedures
2.3-Enviam ou recebem parâmetros de informação
3-DataAdapter que fazem o meio de campo entre a app e os componentes de acesso a dados
4-DataReader que são os componentes que armazenam os dados em si que a aplicação pode acessar.
ADO ( Access Data Objects ).
Para melhor suportar o modelo 'desconectado', o ADO.NET os componentes foram separados em 2 partes :
1-Acesso a dados- Exemplo: DataSet
2-Manipulação de dados. - Exemplo : Data Provider
A classe ADO é composto por :
1-Uma conexão com um banco de dados (Connection ).
2-Um objeto para envio de comandos (Command ).
3-Um objeto para adaptar a fonte de dados com o Framework(Data Adapter).
4-Um objeto para leitura dos dados (Data Reader).
5-Um objeto para tratamento de procedures (Parameter).
6-Um objeto para tratamento de erros(Exception).
Tipo de Classes do ADO :
O ADO tem 3 tipos de classes de acordo com a conexão com os bancos de dados que elas fazem :
Classes Desconectadas ( disconnected ) :
É o método básico de acesso ao banco de dados. Exemplo : Classe DataTable.
Os objetos desta classe conseguem armazenar as informações mesmo depois de desconectados do banco de
dados.
Contudo, se algum dado for alterado no banco de dados este objeto não receberá as atualizações.
Classes Compartilhadas ( Shared ) :
1-São as classes que compartilham informações entre todos os 'Data Providers'
Todas as namespaces de acessos a dados são adicionadas fazendo referencia a Namespace específica do Objeto.
Muitas das NameSpaces só estarão disponiveis se seus respectivos 'drivers' estiverem instalados. Por exemplo, para utilizar a namespace SQLClient, System.Data.OracleClient, System.Data.OleDb primeiros temos que instalar os clients desses objetos.
NameSpaces associadas ao ADO :
1-System.Data (Nativo da plataforma .NET)
1.1-Define os objetos DataSet e DataTable
1.2-Adicionar a referêcia a NameSpace System.Data.
2-System.Data.OleDb
2.1-Acesso a fontes de dados Microsoft Access e SQL da versão 7 ou anterior
2.2-Adicionar a referêcia a NameSpace System.Data.OleDB
2.3-Define os objetos
OleDb.OleDbConnection ,
OleDb.OleDbCommand, OleDbDataAdapter, OleDbDataReader, OleDbParameter e OleDbException.
3-System.Data.SQLClient
3.1-Acesso ao Microsoft SQL Server.
3.2-Adicionar a referêcia a NameSpace
System.Data.SQLClient
3.3-Define os objetos
SqlConnection, SqlCommand,
SqlDataAdapter, SqlDataReader, SqlClient.SqlParameter e SqlException.
Elemento 2 : Interno ao ASP NET - System.Data
O Elemento 1 permitiu o acesso ao banco de dados. Este segundo elemento é o que traz os dados ou executa as funcionalidades do servidor sql
Os elementos mais comuns são :
1-Data Adapter
2-Data Table
3-DataSet
Estes elementos pertencem ao System.Data.
O elemento 1 (dll externa ao ASP NET) se comunica com o elemento 2 (interno ao ASP NET) e envia os dados obtidos para dentro do ASP NET.
NameSpace System.Data
1. Todos sabemos que a Microsoft no ASP NET agrupou as classes com funcionalidades semelhantes dentro de uma NameSpace. Portanto, se vamos trabalhar com arquivos a namespace a ser adicionada é a System.IO e no caso de acesso a banco de dados a NameSpace é a System.Data que é um conjunto de classes de acesso a dados.
Note que o System.Data é um componente INTERNO ao ASP.NET e ao abrir um projeto web mesmo que vazio a referência ao System.Data é feita por default de projeto.
O System.Data é o componente de acesso a dados e por esse motivo dentro dele temos tudo que um banco de dados pode ter e por isso ele é tão extenso.
Na página da Microsoft temos uma descrição detalhada dessa NameSpace.
Notas
1-Devido ao fato de tudo no OOP ser objeto tudo na NameSpace Sytem.Data são classes, Interfaces,
Enumerações, Delegates.
2-Quando disse que neste componente temos acesso a tudo do banco de dados nos referimos não só aos dados
mas também as estruturas, aos recursos (constraints por exemplo) que um servidor de banco de dados
pode ter.
3-A classe System.Data contém muitos itens e os mais básicos que todo programador deve conhecer eu coloquei
em negrito.
System.Data - Classes
No link acima temos a descrição das classes ( Constraint, ConstraintCollection, ConstraintException, DataColumn, DataColumnChangeEventArgs, DataColumnCollection, DataException, DataReaderExtensions, DataRelation, DataRelationCollection, DataRow, DataRowBuilder, DataRowChangeEventArgs, DataRowCollection, DataRowComparer, DataRowComparer<TRow>, DataRowExtensions, DataRowView, DataSet, DataSysDescriptionAttribute, DataTable, DataTableClearEventArgs, DataTableCollection, DataTableExtensions, DataTableNewRowEventArgs, DataTableReader, DataView, DataViewManager, DataViewSetting, DataViewSettingCollection, DBConcurrencyException, DeletedRowInaccessibleException, DuplicateNameException, EnumerableRowCollection, EnumerableRowCollection<TRow>, EnumerableRowCollectionExtensions, EvaluateException, FillErrorEventArgs, ForeignKeyConstraint, InRowChangingEventException, InternalDataCollectionBase, InvalidConstraintException, InvalidExpressionException, MergeFailedEventArgs, MissingPrimaryKeyException, NoNullAllowedException, OrderedEnumerableRowCollection<TRow>, PropertyCollection, ReadOnlyException, RowNotInTableException, StateChangeEventArgs, StatementCompletedEventArgs, StrongTypingException, SyntaxErrorException, TypedTableBase<T>, TypedTableBaseExtensions, UniqueConstraint e VersionNotFoundException)
System.Data - Classes
No link acima temos a descrição das interfaces ( IColumnMapping, IColumnMappingCollection, IDataAdapter, IDataParameter, IDataParameterCollection, IDataReader, IDataRecord, IDbCommand, IDbConnection, IDbDataAdapter, IDbDataParameter, IDbTransaction, ITableMapping, ITableMappingCollection)
System.Data - Enumerações
No link acima temos a descrição das enumerações ( AcceptRejectRule, CommandBehavior, CommandType, ConflictOption, ConnectionState, DataRowAction, DataRowState, DataRowVersion, DataSetDateTime, DataViewRowState, DbType, IsolationLevel, KeyRestrictionBehavior, LoadOption, MappingType, MissingMappingAction, MissingSchemaAction, ParameterDirection, Rule, SchemaSerializationMode, SchemaType, SerializationFormat, SqlDbType, StatementType, UpdateRowSource, UpdateStatus, XmlReadMode, XmlWriteMode).
System.Data - Delegates
No link acima temos a descrição dos delegates ( DataColumnChangeEventHandler, DataRowChangeEventHandler, DataTableClearEventHandler, DataTableNewRowEventHandler, FillErrorEventHandler, MergeFailedEventHandler, StateChangeEventHandler, StatementCompletedEventHandler)
Objetos nativos de acesso a dados
1-DataReader:
1-Se você pretende ler os dados do Data Source mas não vai manipular, alterar, eliminar, apenas transferir de um
componente /objeto para outro, utilize a classe DataReader.
2-Se você deseja acessar um banco de dados mas não pretende reter as informações, você pode usar o objeto
Comando para criar um DataReader.
O objeto DataReader precisa da conexão aberta para acessar os dados e sempre trabalha forward-only e read-only.
Proporciona um método de acesso de alto-desempenho e read-only.
Dentro do System.Data temos 2 data readers dedinidos : IDataReader e DataTableReader
2-Data Adapter
1-O DataAdapter obtém as informações do banco de dados mas são os objetos DataSet ou DataTable que armazenam as
informações.
2-Tanto DataSet como DataTable são sem conexão, ou seja, mesmo desconectadas retém a informação
obtida.
Digamos que o DataSet e DataTable trazem a informação para a memória do computador
( in-memory database ).
Desvantagem : Se a informação for alterada no banco de dados, você não ficará sabendo.
O Data Adapter proporciona uma 'ponte' entre o 'DataSet' e o 'Data Source'.
Dentro do System.Data temos 2 data adapters dedinidos : IDataAdapter e IDbDataAdapter.
3-O DataSet :
1-É o componente central da arquitetura 'desconectada' do ADO.NET.
2-Pode conter uma coleção de DataTables, registros, campos, pks, fks, constraints,
Cuidado : NÃO CONFUNDIR 'OLE DB .NET DATA PROVIDER' com os genéricos 'OLE DB PROVIDERS'. Os 'OLE DB .NET DATA PROVIDER'
são feitos pela própria Microsoft e colocados na plataforma ASP NET nativamente da plataforma.
Os 'OLE DB PROVIDERS' são componentes externos ao .NET e são obtidos instalando componentes fornecidos pela empresa
que suporta o banco de dados.
Dentro do System.Data temos 1 data set dedinido : DataSet.
Sequencia de operações
1-A primeira coisa a ser definida é o correto string de conexão.
Seu formato depende totalmente da fonte de dados e pode conter usuário, senha, nome do servidor,
nome da instância da base de dados, se a conexão é trusted com o Windows etc.
2-A segunda coisa a fazer é abrir a conexão com o banco de dados.
O Banco de dados é chamado de Data Source do programa.
Esta funcionalidade não retorna dados mas retorna o status indicando
se a conexão foi ou não aceita.
Se a conexão for recusada não adianta prosseguir, todos os comandos enviados darão erro pois
a conexão é a ponte que conecta a fonte de dados ao consumidor desses dados.
3-A terceira coisa é montar e testar a querie.
Normalmente faço o teste com uma ferramenta externa (tipo mySQL Admin, mySQL Workbench) e ai
trago para a minha página ASP e faço as modificações.
4-A quarta coisa é executar a consulta.
5-A quinta coisa é verificar se a consulta foi executada com sucesso. Para isso verificamos o status retornado pela execução da querie. Se deu erro algumas etapas abaixo devem ser puladas.
6-Caso tenha sucesso os dados podem ser enviados ao controle que consumirá os dados. Pode ser um gridview, um data repeater ou coisa parecida.
Deve-se liberar os objetos de dados (data reader/adapter, datatable, dataset) colocando eles como null e finalmente fechar a conexão com o banco de dados. Note que fechar o banco de dados pode ser o passo 5 caso os objetos de acesso a dados sejam objetos desconectados das bases de dados.
Importante : Sabemos que ao colocar null nos objetos de acesso a dados apenas torna eles inativos
no sistema e que na realidade não libera memória pois o 'Garbage Collector' do .NET só roda depois
que a aplicação finalizar completamente, ou seja, depois que a página for totalmente enviada ao
cliente.
Contudo as regras e boas práticas pedem para que isso seja feito especialmente para não utilizar
esses objetos 'sujos' com dados de pesquisas anteriores.
Classes de acesso a dados do .NET Framework.
Usando um objeto DataSet
O DataSet é uma representação relacional baseada em memória de dados e o principal objeto desconectado de dados conectado.
O DataSet contém uma coleção de objetos DataTable e DataRelation.
Os objetos do DataTable podem conter restrições de chave exclusivas e estrangeiras para reforçar a integridade dos dados.
O Data-Set também fornece métodos para clonar o esquema DataSet, copiar o DataSet, mesclar com outros objetos DataSet e recuperando
alterações do DataSet.
DataTable
O objeto DataTable contém os objetos DataColumn os quais definem o esquema a que pertencem.
O objeto DataTable também contém os objetos DataRow que contém os dados.
Os Objetos DataRow contém as propriedades RowState e DataRowVersion.
A propriedade RowStateindica se o DataRow deve ser inserido, atualizado ou eliminado da base de dados.
O objeto DataRow contém uma cópia dos dados da base de dados. Este recurso possibilita o roll back de dados.
O objeto DataSet é uma representação em memória dos dados no banco de dados com todas as suas propriedades
relacionais. Portanto, o objeto DataSet contém as coleções de objetos DataTable e DataRelation
Os objetos DataSet e DataTable podem ser serializados ou desserializados de um stream ou XML.
Os dados do DataSet, DataTable e DataRow podem ser anexados(mergeados) dentro de um objeto
DataSet.
O recurso LINQ para o DataSet contém um mecanismo que permite escrever complexas queries contra dados na memória
usando C# ou VB NET.
Classes Conectadas do ADO.NET
São classes que transferem dados do lado do servidor(BD) para o lado do cliente(Web Server).
Principais classes de Acesso a dados (Access Providers)
OleDb Classe para acesso a bases de dados genéricas de muitas fontes de dados
Elas proporcionam acesso a bd muito antigas ( como o MS SQL SRV 6.5 e versões anteriores) ou
a bd não nativas da Microsoft, como Sybase, DB2/400 e o Microsoft Access.
ODBC É uma classe de uso geral para diversas bases de dados. São classes 'antiquadas' que são usadas
quando nenhum novo método de acesso foi desenvolvido para o bd.
Não é muito utilizado porque depende de configuração local na máquina do cliente muitas vezes.
SQL Server É uma classe desenvolvida exclusivamente para o MS SQL Server e é muito similar ao
'provider' OLEDB, só que exclusivo para bd SQL Server.
Esta classe são feitas para as versões 7, 2005 e 2008.
Oracle É uma classe desenvolvida exclusivamente para o bd Oracle para acessar o listener fornecido pela própria Oracle. É similar ao OleDb mas tem performance superior.
Principais Providers dentro das Classes
Acesso aos Bancos de dados
1-A primeira coisa que você precisa ter é uma fonte de dados e uma maneira de acessá-la.
A natureza dessa fonte de dados muitas vezes determina como devemos acessá-la
porque, seja qual for, foi feita uma classe ou específica ou genérica que faz isso
.
Praticamente sempre você vai precisar de alguma ferramenta para acessar um banco de dados.
Se for um bd Access você vai precisar do Office. Não se esqueça que se o office for de 32 bits
você deverá compilar a sua app como 32 bits senão as dlls do office não estarão disponíveis para
a sua aplicação. Os componentes para este tipo de bd estão no Microsoft Data Objects que
são instalados com o office ou você poderá baixar o MDACTYPE para isto.
Se a bd for MS SQL SRV, você precisará instalar o SQL Client pelo menos, no caso de sua máquina
não ser também a servidora do banco de dados. Normalmente, se sua máquina é o servidor web
é recomendado que o servidor de banco de dados seja outra máquina, não só para ter maior
performance mas por motivos de segurança.
Se se bd for um Oracle você precisa instalar um client compatível com a versão da base de dados
que deseja acessar. A bd Oracle fala com o resto do mundo através de um tunelamento, chamado Listener.
Este objeto vem junto com o client.
2-Depois da base de dados acessível (servidor, local) a próxima coisa que você vai precisar é da classse Connection (DBConnection).
3-Para fazer a connexão você precisa determinar os parâmetros que serão usados como servidor, base de dados,
usuário, senha, tipo de autenticação, etc. O objeto que define esses parâmetros é chamado de string de conexão.
Quando essas informações foram definidas, podemos abrir a conexão com a fonte de dados.
Importante : Nunca se esqueça de fechar a conexão com o banco de dados.
4-Os parâmetros de conexão são : Servidor(Server), Base de dados(Database), Usuário(User), Senha(Password) e o
tipo de segurança envolvida que pode ser integrada com o windows (trusted connection).
Sendo assim um string de conexão pode ser desta maneira:
SQL Client
"Server=xxxx;Database=yyy;Trusted_Connection=true";
"Server=xxxx;Database=yyy;User=zzz,Password=kkk";
OLEDB
"Data Source=xxxx;Initial Catalog=yyy;integrated security=true";
"Data Source=xxxx;Initial Catalog=yyy;trusted_connection=true";
"Data Source=xxxx;Initial Catalog=yyy;UID=zzz,pwd=kkk";
ODBC
A conexão com o ODBC normalmente utiliza parametros salvos em arquivos .udl(Universal Data Link).
Os arquivos .udl são arquivos tipo texto simples.
Exemplo:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\pasta\arqAccess.mdb;Persist Security Info=False;
Objeto DBCommand
É ele que envia o comando ao SQL Server informando o que você deseja fazer com os dados do servidor.
O objeto DBCommand pode enviar os 3 tipos de comandos possíveis para o SQL Server:
Data Manipulation Language(DML) Este é o comando normalmente usado para enviar ou receber infos do servidor SQL. Os comandos DML mais comuns são insert, update e até o delete.
Data Description Language(DDL) É a linguagem usada para modificar a estrutura de tabelas e outros itens do servidor SQL Server. Os comandos DDL mais comuns são o Alter (Database, Table, etc..)
Data Control Language(DCL) São o conjunto de comandos para permitir ou definir o acesso dos usuários ao servidor colo logins, schemas, users, etc.
O objeto DBCommand sempre é dado contra uma conexão já aberta.
O objeto DBCommand tem as propriedades CommandText e CommandType para definir o que deve ser feito e como.
Por exemplo, para chamar uma Stored Procedure o parâmetro CommandText tem que ser exatamente o nome da procedure
a ser chamada (cmd.ConnectionText="userStoredProc") e o parâmetro CommandType deve indicar que o alvo do comando
é uma stored procedure (CommandType=CommandType.StoredProcedure).
Ainda, no caso de Stored Procedures o objeto DBCommand armazena os parâmetros a serem passados para a Stored
Procedure com a sintaxe : cmd.Parameters("campo").Value.
Resultado ou retorno de dados
Tipos de Resultados das Queries
Podemos ter 3 tipos de resultados ao executar uma querie:
1-Não retorna nada além de um Status (ExecuteNonQuerie) : É um comando que ao ser executado no SQL não retorna nenhum
dado.
Como exemplo cito os comandos delete, truncate table x.
2-Retorna um dado apenas (ExecuteScalar) : Acontece quando o SQL Server retorna um dado, apenas uma linha de resposta.
Esta linha única de dados pode ser um número inteiro, um tipo longo ou um string. Como o .NET é uma linguagem
fortemente tipada, o tipo do retorno é critico para não dar erro na execução da querie.
O exemplo típico deste tipo de querie é um Select count(*) from tabela.
3-Retorna um DataSet ( ou RecordSet como era dito antigamente ) : Retorna um conjunto de dados de uma tabela ou de outro elemento que retorna diversos campos e diversas linhas de dados.
Além do tipo do resultado o objeto DBCommand define o acesso as informações e devemos seguir as regras do objeto criado para acessá-las.
Tipo de resultado desejado
1-cmd.ExecuteReader o cursor criado no servidor para este tipo de comando só permite
acessar as informações apenas para leitura, apenas para frente.
Combinando este controle com o DBExecuteReader temos o controle de acesso a dados ideal para preencher
ListBox, DropDownList e GridView desde que se deseje apens ler e não modificar os dados.
Exibindo as informações obtidas
1-ListBox Control É um dos controles mais simples e mais fáceis de usar do .NET Framework porque ele
simplesmente exibe o dado, não permite edição ou qualquer outra ação. Possui uma coleção
de itens e cada item desta coleção é chamado de ListItem. O Objeto ListItem tem uma propriedade chamada Text que é
o texto exibido ao usuário e a propriedade Value que é o valor do item que poderá ser enviado de volta
ao servidor num postback.
Exemplo:
<asp:ListBox ID="lstbox1" runat="server" DataSourceID="sqlsrv1" DataTextField="Campo1" DataValueField="Campo2">
</asp:listbox>
2-DropDownList Control Exibe uma lista de opções para que o usuário escolha uma delas.
Também possui uma coleção de itens. Para determinar qual valor foi selecionado temos as propriedades
SelectedValue ou SelectedIndex.
Exemplo:
<asp:DropDownList DataSourceID="SrvSQL1" DataTextField="Campo1" DataValueField="Campo2">
</asp:DropDownList>
3-CkeckBox eRadioButton List Controls São controles muito usados em asp net e podemos associar
eles aos dados retornados do BD. O único inconveniente seria que seria um checkbox ou radiobutton para
cada registro retornado do banco de dados
Exemplo:
<asp:CheckBoxList DataSourceID="SrvSQLx" DataTextField="Campo1" DataValueField="Campo2">
</asp:DropDownList>
4-BulletList Control Este controle pode ser exibido com(ol) ou sem ordem(ul). Através da propriedade
BulletStyle podemos controlar a aparência deste controle(Disc, Circle ou Square).
Infelizmente nem todos os browsers tem esses estilos mas podemos colocar uma imagem no lugar do bullet.
A propriedade bullet style também pode trocar o bullet por números ( romanos, arábicos ), por letras(A a Z-
maiúsculas ou minúsculas) ou mesmo começar a contagem de itens a partir de um número desejado.
Controles Data-Bound Compostos
São controles que podem exibir os headers dos campos bem como os dados desses campos.
GridView
É o mais famoso e versátil item de exibição de dados vindos de bancos de dados.
Neste controle podemos mover as colunas para a ordem que desejamos, ordenar, paginar, editar entre
outros recursos.
Lembra muito uma planilha do Excel.
O GridView possui uma coleção de GridViewRow (registros) e GridViewField (campos). O GridViewRow herda as
propriedades do objeto TableRow e o GeidViewField herda as propriedades do objeto cell.
Uma das características mais interessantes deste controle é que possui propriedades para mudar seu
estilo para qualquer tipo que o usuário deseje. Propriedades como GridViewStyle, HeaderViewStyle, FooterStyle,
RowStyle, Alternating-RowStyle(Famoso zebradinho) são padrões que formatam e padronizam os estilos
de acordo com boas sugestões da Microsoft.