none
Duvidas Simples sobre ADO.Net e TableAdapter RRS feed

  • Pergunta

  • Ola pessoal
    tenho algumas duvidas
    1)Quando crio um DataSet com 2 tabelas, e elas possuem um relacionamento, é melhor que eu crie esse relacionamento no Banco ou no DataSet?
    Eu acredito que seja no bando, porem, nao tenho certeza disso!
    2)O TableAdapter, ele trabalha de forma On-Line ou Off-Line com os dados?
    Se ele trabalha Off-Line, onde fica armazenado os dados, na memória do servidor(como sessao?) ou do cliente?
    Existe como eu controlar aonda fica armazenada esses dados, se no cliente ou no servidor?
    3)quando instancio um objeto do tipo DataSet, ele precisa fechar a conecçao ao o banco ou ele faz isso sozinho?
    que nem no codigo abaixo

    public void Incluir(string NomeProduto)

    {
        dsTableAdapters.
    ProductsTableAdapter ta =new         dsTableAdapters.ProductsTableAdapter();

    ta.Insert(NomeProduto);
    }


    Nesse caso eu nao precisaria ao fazer o Insert fechar a conexao?

    Bem, acho que é so por enquanto
    abs
    T+
    terça-feira, 3 de abril de 2007 23:49

Respostas

  • Eu queria discordar do Dennes um pouquinho aqui Smile

     

    Quanto à pergunta 1, eu responderia: Sempre no banco, e às vezes no DataSet. aliás, no dataset, na maoria das vezes você não vai querer fazer isso. por que? Primeiro porque não precisa, segundo porque vai te atrapalhar uma série de operações. O relacionamento no dataset só vai ser útil em caso de navegação entre entidades (se voce quiser, por exemplo, um grid que faz drill entre tabela pai e filho).

     

    2-Nada  a acrescentar, só tomar cuidado com isso de querer guardar os dados, isso pode matar a aplicação

     

    3-Na dúvida, abra e feche explicitamente as conexões, inclusive com um try que fecha em caso de erro. Até porque vai ter casos onde você vai querer executar mais de um Fill na mesma conexão.

     

     

    quarta-feira, 4 de abril de 2007 02:29
  • Da pra mandar pro cliente também, mas sinceramente eu considero suicício. Você pode guardar um dataset num viewstate, mas vai ficar horrível Smile

     

     

    public void Incluir(string NomeProduto)

    {
        dsTableAdapters.ProductsTableAdapter ta =new         dsTableAdapters.ProductsTableAdapter();

    ta.Connection.Open();

    ta.Insert(NomeProduto);

    ta.Connection.Close();
    }

     

    Daí voce pode por um try..catch para em caso de erro ver se a conexao está aberta e fecha-la.

    quarta-feira, 4 de abril de 2007 05:29
  • Oi !

     

    O ASP.NET possui um objeto Cache que equivale ao objeto Application onde pode-se guardar pequenos datasets (não recomendaria para grandes datasets). O objeto Cache é mais avançado que o objeto application, possui controle de dependência e pode-se fazer diversos truques com o controle de dependência de forma que o cache seja invalidado assim que os dados forem alterados.

     

    Para grandes conjuntos de dados o ideal é fazer custom paging, ou seja, trazer página por página de dados do servidor. O objectDataSource fornece essa opção, precisando de métodos específicos para o custom paging. Com uma tabela grande, pode não ser muito adequado que a cada  10 registros ele faça um select de 10.000 .

     

    Quanto a conexão, na maioria dos casos o objectDataSource vai fazer todo o trabalho para você. A abertura e fechamento explicito apenas gera ganho quando você tem um componente executando um processo que envolve vários tableadapters. Nesse caso o tableAdapter é capaz de identificar que a conexão  já encontra-se aberta e você tem uma abertura única de conexão para um bloco de instruções.

     

    []'s

     

    quarta-feira, 4 de abril de 2007 10:15

Todas as Respostas

  •  

    Oi !

     

    1) Nos dois

     

    2) Off-Line. Não fica armazenado em lugar algum, se você está falando de páginas web, a cada novo request tudo é montado novamente, dai que existem algumas técnicas mais avançadas de cache.

     

    3) Ele só abre a conexão ao banco no momento em que o tableAdapter faz um fill do dataset e fecha a conexão automaticamente. No seu exemplo do insert, a conexão é aberta e fechada automaticamente.

     

     

    []'s

     

     

    quarta-feira, 4 de abril de 2007 00:12
  • Eu queria discordar do Dennes um pouquinho aqui Smile

     

    Quanto à pergunta 1, eu responderia: Sempre no banco, e às vezes no DataSet. aliás, no dataset, na maoria das vezes você não vai querer fazer isso. por que? Primeiro porque não precisa, segundo porque vai te atrapalhar uma série de operações. O relacionamento no dataset só vai ser útil em caso de navegação entre entidades (se voce quiser, por exemplo, um grid que faz drill entre tabela pai e filho).

     

    2-Nada  a acrescentar, só tomar cuidado com isso de querer guardar os dados, isso pode matar a aplicação

     

    3-Na dúvida, abra e feche explicitamente as conexões, inclusive com um try que fecha em caso de erro. Até porque vai ter casos onde você vai querer executar mais de um Fill na mesma conexão.

     

     

    quarta-feira, 4 de abril de 2007 02:29
  • 1)
    nos 2?
    vc me diz para fazer nos 2 ou que nos 2 casos da no mesmo?

    2)quando eu abilito por exemplo o "ordenar", e cada vez que o usuario click na coluna que deseja a ordem, ele vai ao banco e busca novamente os dados?

    obrigado
    abs
    T+
    quarta-feira, 4 de abril de 2007 02:34
  •  

    Oi !

     

    1) Eu quero dizer fazer nos 2. No banco é essencial, sem sombra de dúvida. No dataset o próprio objeto dataset já reconhecerá os relacionamentos do banco, acho pouco frequente que esses relacionamentos atrapalhem você e precise tira-los, na maioria dos casos o relacionamento vai ajuda-lo.

     

    2) Exatamente. Por isso existem diversas técnicas de cache, do mais básico até técnicas bem avançadas para controlar cuidadosamente o tráfego entre servidor web e servidor de banco.

     

    []'s

     

    quarta-feira, 4 de abril de 2007 02:45
  • A pergunta 1 eu acho que já respondi Smile

     

    Quanto à 2: Se voce coloca o order by no select, o banco vai fazer isso. Se você muda a ordenação no dataset, ele faz isso em memória.

     

    Mas...

     

    Se é uma aplicação Web, significa que quando voce recebeu a página, os objetos ali ja morreram, incluindo o dataset. daí se voce clicar em ordenar, a página vai carregar de novo, executar o select de novo, carregar de novo os dados e mandar.

     

    E sinceramente?

     

    Assim que é bom. Smile

     

    Se a sua preocupação é guardar isso em memória por causa desse tipo de coisa, minha sugestão é: Não esquenta com isso não. O banco de dados é o melhor cara para cuidar disso.

     

    quarta-feira, 4 de abril de 2007 02:45
  • Oi !

     

    Melhor cara para cuidar da ordenação, com certeza.

     

    O problema é que a ordenação do gridview não é feita em banco. A cada vez que o usuário clica em ordenar ele faz o select no banco, o mesmo select, e faz a ordenação na memória do servidor web.

     

    Portanto não é pela ordenação que vai-se gastar uma ida a mais de banco.

     

    O cache precisa ser analisado tabela a tabela, caso a caso para encontrar a forma adequada aquele caso.

     

    []'s

     

    quarta-feira, 4 de abril de 2007 02:55
  • Sinceramente? Prefiro ir ao banco.

     

    Da pra customizar isso, tratar um evento e montar o select de acordo.

     

    Mas sim, considerando que DataSet no Framework 2 tem índice, da pra fazer isso em memória a um custo razoavelmente baixo. Mas já que você vai ter que retornar o select do banco do mesmo jeito, por que não já colocar o order by de acordo com o que foi clicado no grid?

    quarta-feira, 4 de abril de 2007 03:02
  • Oi !

     

    Ai é que está, com as técnicas adequadas de cache, você não vai ter que fazer o select no banco.

     

    []'s

     

    quarta-feira, 4 de abril de 2007 03:05
  • Não deixa de ser uma opção...

     

    Tem que avaliar quanto isso significa em termos de memória no servidor x usuários concorrentes x quantidade de telas onde se deseja fazer isso e ver se no final nao sai caro.

    quarta-feira, 4 de abril de 2007 03:24
  • Ola pessoal
    obrigado pela "discução" sobre o assunto
    como podem ver, sou iniciante em .Net
    Trabalho com ASP e SQL Server 2000/2005.
    Tenho feito alguns teste em Asp.Net, e tenho gostado muto, praticamente o que eu demoraria 1 semana pra fazer, demoro 1 dia em Asp.Net.(tirando pela parte de planejamento e tudo mais.)
    Sobre as duvidas que tenho.
    Quando vi essa parte de ordenação, fiquei com receio em abilitar pois,
    1-se ele guarda no servidor, provavelmente seria como sessão, e se tenho muitos dados no Grid, isso traria uma perca consideravel de performance
    2-se ele ordena e faz um novo acesso ao banco de dados, melhor tomar cuidado, pois se a consulta é grande, isso pode me trazer problemas
    3-se ele de alguma forma guarda isso no cliente, tomar cuidado na parte de segurança, com questao de acesso a memoria, copia de dados, entre outras coisas que nao é tao dificil de se fazer(uma busca em sites de pesquisa e vc encontra muitas coisas)

    Mais em ambos os casos, verificar o custo beneficio é a melhor forma, até as vezes nem é tao necessario dar a opção do usuario escolher por qual coluna ele quer ordenar(ja vi em alguns casos que muitas opções chegam mais a atrapalhar do que ajudar, fora ter que criar um selec para cada ordem que vc criar[ja vi alguns caso em que o programador concatena o ORDER BY no final do select, porem nao acho isso uma opção "boa", por questao de performance e segurança]  pode gerar um código imenso fora a manutencao que isso vai acabar gerando).

    Mateus Velloso , poderia me dar um exemplo da duvida 3, onde vc diz para abrir e fechar explicitamente, um codigo simples.

    Bem obrigado a todos
    abs
    T+

    quarta-feira, 4 de abril de 2007 04:58
  • Da pra mandar pro cliente também, mas sinceramente eu considero suicício. Você pode guardar um dataset num viewstate, mas vai ficar horrível Smile

     

     

    public void Incluir(string NomeProduto)

    {
        dsTableAdapters.ProductsTableAdapter ta =new         dsTableAdapters.ProductsTableAdapter();

    ta.Connection.Open();

    ta.Insert(NomeProduto);

    ta.Connection.Close();
    }

     

    Daí voce pode por um try..catch para em caso de erro ver se a conexao está aberta e fecha-la.

    quarta-feira, 4 de abril de 2007 05:29
  • Oi !

     

    O ASP.NET possui um objeto Cache que equivale ao objeto Application onde pode-se guardar pequenos datasets (não recomendaria para grandes datasets). O objeto Cache é mais avançado que o objeto application, possui controle de dependência e pode-se fazer diversos truques com o controle de dependência de forma que o cache seja invalidado assim que os dados forem alterados.

     

    Para grandes conjuntos de dados o ideal é fazer custom paging, ou seja, trazer página por página de dados do servidor. O objectDataSource fornece essa opção, precisando de métodos específicos para o custom paging. Com uma tabela grande, pode não ser muito adequado que a cada  10 registros ele faça um select de 10.000 .

     

    Quanto a conexão, na maioria dos casos o objectDataSource vai fazer todo o trabalho para você. A abertura e fechamento explicito apenas gera ganho quando você tem um componente executando um processo que envolve vários tableadapters. Nesse caso o tableAdapter é capaz de identificar que a conexão  já encontra-se aberta e você tem uma abertura única de conexão para um bloco de instruções.

     

    []'s

     

    quarta-feira, 4 de abril de 2007 10:15
  • Nossa! Essa Thread resolveu várias dúvidas minha!

     

    Gostaria de aproveitar e fazer uma pergunta utilizando o mesmo contexto. Vamo supor que uma dessas tabela seja cliente e outra seja telefones_cliente. Como faço para que o segundo TableAdapter filtre por cod_cli? Tem algo automatizado no VB?

    quinta-feira, 12 de abril de 2007 23:46
  • Você quer filtrar no banco de dados ou na memória? Se for no banco, é clausula where no seu select. Se for na memória, criando o relacionamento no dataset como o Dennes sugeriu te permite fazer essa navegação de parent para child
    sexta-feira, 13 de abril de 2007 07:54
  • Seria na memória mesmo. Então o relacionamento no dataset já filtra quando vc seleciona um row? Por exemplo, usando meu exemplo anterior, mudando de registro de cliente, ele atualiza automaticamente o filtro de telefones?

     

     

    sexta-feira, 13 de abril de 2007 11:15
  •  Mateus Velloso wrote:
    Você quer filtrar no banco de dados ou na memória? Se for no banco, é clausula where no seu select. Se for na memória, criando o relacionamento no dataset como o Dennes sugeriu te permite fazer essa navegação de parent para child

     

    Pelo que andei vendo, se é feito o relacionamento direto no banco, quando se constrõe-se o dataset, ele já importa todo o relacionamento. Só que eu percebi que quando a conexão é por ODBC, ele não faz isso.  OK. Construi o relacionamento manualmente mesmo. Ao executar, ele dá o seguinte erro:

     

    Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints.

     

    E nas sugestões:

     

    Relax or turn off constraints in your DataSets.

    You can use the EnforceConstraints property to temporarily turn off constraints while filling tables in a DataSet object.

    Make sure you are not trying to assign a value to a primary key field where the primary key already exists in the data table.

    If the primary key exists, this exception is thrown.

    For more information, Visual Basic users can see How to: Update a Data Source with the Contents of Related DataTables (Visual Basic).

    Clear datasets before loading them from view state.

    If there is data in the dataset when you load it, this exception may be thrown.

    Pelas mensagens, o relacionamento está corrompido. Mas não está pois ele está feito no banco. Alguém já viu isso?

     

     

    quinta-feira, 19 de abril de 2007 23:41
  • Eh, aí começam os problemas de quando voce tem um DataSet com relacionamentos.

     

    O que acontece é o seguinte:

     

    Imagina uma tabela pai e uma filha, com um relacionamento no dataset. Se voce popular a filha primeiro, vai dar esse erro, porque o dataset nao pode ter registros filhos sem os registros pais.

     

    Então ou voce muda a ordem com que carrega os dados, ou desabilita alguns relacionamentos.

     

    Essa é a parte chata de lidar com esses relacionamentos lá.

    quinta-feira, 19 de abril de 2007 23:48
  • Foi exatamente isso que aconteceu...hehehe. O próprio VB cria o código para popular o DataAdapter.

    E mesmo assim o relacionamento não funcionou. Então criei um novo Fill com entrada do código. E fiz ele popular o DataAdapter toda vez que o cod no TextBox é alterado. Achei meio gambiarra...hehehe, mas não achei nenhum outro evento melhor.

     

    Valeu!!!

    sexta-feira, 20 de abril de 2007 00:03