DIFICULDADE ENTENDER MUDANCA ADO PARA DOT NET
Boa tarde.
Estou tendo várias dúvidas quando a utilização do Dot.net para acesso ao banco de dados SQL Express 2005 e C# 2008.
Meu problema está sendo entender os tais DataTable, DataAdapter, etc.. para manipulação dos dados, inclusive no acesso a Stored Procedures do banco e formatação dos dados para gravar e checar se já existem antes de gravar.
Moro no cidade de Nova Odessa - SP, entre Americana e Sumaré. Tem alguém aqui no forum que more nas proximidades, que domine estas ferramentas e possa me dar uma aula sobre isso para que eu possa entender a lógica e assim seguir em frente? Acertaremos o valor e data por telefone. Se houver alguém favor me mandar uma mensagem privada.
Obrigado.
Estou tendo várias dúvidas quando a utilização do Dot.net para acesso ao banco de dados SQL Express 2005 e C# 2008.
Meu problema está sendo entender os tais DataTable, DataAdapter, etc.. para manipulação dos dados, inclusive no acesso a Stored Procedures do banco e formatação dos dados para gravar e checar se já existem antes de gravar.
Moro no cidade de Nova Odessa - SP, entre Americana e Sumaré. Tem alguém aqui no forum que more nas proximidades, que domine estas ferramentas e possa me dar uma aula sobre isso para que eu possa entender a lógica e assim seguir em frente? Acertaremos o valor e data por telefone. Se houver alguém favor me mandar uma mensagem privada.
Obrigado.
Eu possuo este livro:
Visual c# 2008 passo a a passo
e aprendi muito sobre isso nele.
Visual c# 2008 passo a a passo
e aprendi muito sobre isso nele.
Eu já comprei 2 livros, mas cada um cria um monte de dúvidas a mais, pois cada um tem exemplos completamente diferentes para fazer [Ô]Coisas Semelhantes[Ô].
Meu problema é encontrar a melhor forma no C# de fazer o que fazia no VB6. Por exemplo:
1- Eu faço tudo desconectado, não uso nenhum DataSource no meu sistema, assim tenho controle absoluto, otimizando e personalizando tudo, apesar de ter mais trabalho na codificação.
2- No meu caso eu não faço bloqueio de nada no banco ao selecionar registros, meu sistema não precisa disso. Assim carrego tudo que preciso (dados de tabelas relacionadas) num FlexGrid (VB6) e ao editar um registro, faço um UPDATE direto na tabela ou tabelas via EXECUTE do ADO.
3- Quando carrego um recordset, depois que povoo o Grid eu o fecho. Com isso estou vendo grande dificuldade nesses DATATABLE, DATAREADER, DATASET etc... pois não preciso ter nada em memória para afetar o banco ao realizar mudanças.
4- A única situação que fico com um Recordset ABERTO, porém igualmente desconectado, é para povoar DBCombo (caixas de listagem) com dados de tabelas básicas, pois uso o ID e Nome nestes controles (o ID para salvar o registro) e o Nome para exibÃr, além de uma função que desenvolvi para autopreenchimento deste controle ao ir digitando caracteres. Esta função usa o recordset, para localizar o dado e assim posicionar o DBCombo no registro correto, pois o DBCombo não possui tal recurso.
Nota: Esta função eu disponibilizei a alguns anos aqui no VBM.
Com vistas ao que expliquei acima, surgem inúmeras dúvidas. Além da adaptação o sistema para OOP, tem a mudança do ADO para ADO.Net.
Estou pesquisando hoje alternativas para não ter de usar esses DATA... todos já que não fico [Ô]Conectado[Ô] ao banco ou tenho de refletir as mudanças destes objetos.
Estou vendo se dá para usar somente um DATAReader para carregar os dados que preciso do banco, via um SELECT e dar um EXECUTE direto no banco com os Inserte e Updates necessários, com base nos IDs que já tenho no GRID, da mesma forma que fazia com os Recordsets no VB6.
Meu problema é encontrar a melhor forma no C# de fazer o que fazia no VB6. Por exemplo:
1- Eu faço tudo desconectado, não uso nenhum DataSource no meu sistema, assim tenho controle absoluto, otimizando e personalizando tudo, apesar de ter mais trabalho na codificação.
2- No meu caso eu não faço bloqueio de nada no banco ao selecionar registros, meu sistema não precisa disso. Assim carrego tudo que preciso (dados de tabelas relacionadas) num FlexGrid (VB6) e ao editar um registro, faço um UPDATE direto na tabela ou tabelas via EXECUTE do ADO.
3- Quando carrego um recordset, depois que povoo o Grid eu o fecho. Com isso estou vendo grande dificuldade nesses DATATABLE, DATAREADER, DATASET etc... pois não preciso ter nada em memória para afetar o banco ao realizar mudanças.
4- A única situação que fico com um Recordset ABERTO, porém igualmente desconectado, é para povoar DBCombo (caixas de listagem) com dados de tabelas básicas, pois uso o ID e Nome nestes controles (o ID para salvar o registro) e o Nome para exibÃr, além de uma função que desenvolvi para autopreenchimento deste controle ao ir digitando caracteres. Esta função usa o recordset, para localizar o dado e assim posicionar o DBCombo no registro correto, pois o DBCombo não possui tal recurso.
Nota: Esta função eu disponibilizei a alguns anos aqui no VBM.
Com vistas ao que expliquei acima, surgem inúmeras dúvidas. Além da adaptação o sistema para OOP, tem a mudança do ADO para ADO.Net.
Estou pesquisando hoje alternativas para não ter de usar esses DATA... todos já que não fico [Ô]Conectado[Ô] ao banco ou tenho de refletir as mudanças destes objetos.
Estou vendo se dá para usar somente um DATAReader para carregar os dados que preciso do banco, via um SELECT e dar um EXECUTE direto no banco com os Inserte e Updates necessários, com base nos IDs que já tenho no GRID, da mesma forma que fazia com os Recordsets no VB6.
Luiz entendo sua dúvida. no entanto é preciso esclarecer que um dataset hospeda datatables com dados de n tabelas que você busca do banco. neste sentido vc carrega um datatable e desconecta do banco, você não fica conectado direto.
basicamente é seguinte:
vc conecta ao banco;
faz o select;
preenche o datatable;
desconecta do banco;
os dados armazenados no datatable pode ser consultados em tempo de execução sem precisar fazer consultas no banco. neste caso você teria uma tabela [Ô]virtual[Ô] para manipular.
agora você poderia nos informar o que realmente quer fazer para lhe darmos alguma sugestão. seu questionamento foi muito genérico.
estamos no aguardo.
basicamente é seguinte:
vc conecta ao banco;
faz o select;
preenche o datatable;
desconecta do banco;
os dados armazenados no datatable pode ser consultados em tempo de execução sem precisar fazer consultas no banco. neste caso você teria uma tabela [Ô]virtual[Ô] para manipular.
agora você poderia nos informar o que realmente quer fazer para lhe darmos alguma sugestão. seu questionamento foi muito genérico.
estamos no aguardo.
Jonas boa tarde.
Sobre sua colocação
Meu sistema possui vários cadastros, sendo alguns com tabelas básicas:
Departamentos
Cargos
Escolaridade
Cursos
Tipos de Documentos
Etc...
E outros que usam as tabelas básicas para formação de registros especÃficos:
Funcionários (Departamentos, Cargos)
Programa de Sugestões (Funcionários, Departamentos)
Controle de documentos (Funcionários, Departamentos, Normas,Tipos de Documentos, etc...)
Programação de Treinamentos (Funcionários, Departamentos, Cursos, etc...)
Etc...
Cada tela de Cadastro (Inclusão, Consultas, Alterações, etc...) tem um Grid formatado (tamanho de colunas predefinido e algumas colunas ocultas) e campos pra exibição dos dados. No load de cada form eu povoo o Grid com todos os registros (ATIVOS) da tabela correspondente. Ao clicar no Grid e selecionar um registro, eu povoo os campos com os dados selecionados.
Agora eu posso clicar no botões Alterar para editar os campos e quando clicar no botão SALVAR eu gravo todos os dados dos campos (via Classe Modelo + DAL), depois de atribuÃdos dos campos, no banco e altero os dados do registro no grid para não ter de reconsultar no banco.
Nota: Nas tabelas que usam dados de outras, eu gravo apenas o ID da tabela de origem em cada campo.
Ex:
No caso dos funcionários, quando seleciono um e povoo os campos, pego o ID do departamento de lotação dele e jogo no DBCombo (não sei qual o combo do VS 2008 ainda), e assim ele exibe o nome do departamento, pois o DBCombo já foi carregado previamente com todos os departamentos. O mesmo para o ID do cargo no DBCombo Cargos.
Basicamente é isso que eu faço hoje no VB6 com recordset e quero fazer no C#.
Sobre sua colocação
Citação:
vc conecta ao banco; [txt-color=#007100]// ok já tenho[/txt-color]
faz o select; [txt-color=#007100]// ok já tenho[/txt-color]
[txt-color=#e80000]preenche o datatable;[/txt-color]
desconecta do banco; [txt-color=#007100]// ok já tenho[/txt-color]
[txt-color=#e80000]Faltou o preenchimento do grid pelo DataTable[/txt-color]
Meu sistema possui vários cadastros, sendo alguns com tabelas básicas:
Departamentos
Cargos
Escolaridade
Cursos
Tipos de Documentos
Etc...
E outros que usam as tabelas básicas para formação de registros especÃficos:
Funcionários (Departamentos, Cargos)
Programa de Sugestões (Funcionários, Departamentos)
Controle de documentos (Funcionários, Departamentos, Normas,Tipos de Documentos, etc...)
Programação de Treinamentos (Funcionários, Departamentos, Cursos, etc...)
Etc...
Cada tela de Cadastro (Inclusão, Consultas, Alterações, etc...) tem um Grid formatado (tamanho de colunas predefinido e algumas colunas ocultas) e campos pra exibição dos dados. No load de cada form eu povoo o Grid com todos os registros (ATIVOS) da tabela correspondente. Ao clicar no Grid e selecionar um registro, eu povoo os campos com os dados selecionados.
Agora eu posso clicar no botões Alterar para editar os campos e quando clicar no botão SALVAR eu gravo todos os dados dos campos (via Classe Modelo + DAL), depois de atribuÃdos dos campos, no banco e altero os dados do registro no grid para não ter de reconsultar no banco.
Nota: Nas tabelas que usam dados de outras, eu gravo apenas o ID da tabela de origem em cada campo.
Ex:
No caso dos funcionários, quando seleciono um e povoo os campos, pego o ID do departamento de lotação dele e jogo no DBCombo (não sei qual o combo do VS 2008 ainda), e assim ele exibe o nome do departamento, pois o DBCombo já foi carregado previamente com todos os departamentos. O mesmo para o ID do cargo no DBCombo Cargos.
Basicamente é isso que eu faço hoje no VB6 com recordset e quero fazer no C#.
Este texto é bem interessante e mostra bem a relação entre os componentes. http://msdn.microsoft.com/en-us/library/acb32th4(v=vs.90).aspx
Esse objetos têm responsabilidades bem definidas. Um DataTable não faz link direto com o banco de dados (acho que o Macoratti já até esc reveu sobre isso), ele é apenas representação de uma tabela que uma tabela ou query com campos limitados que o DataAdapter buscou no banco de dados. Repare que quem tem métodos para atualizar o banco de dados é o DataAdapter. Vc pode até mandar deletar registros (DataRows) do DataTable, eles são assinalados e ficam em cache e fisicamente não são excluÃdos di banco. Eles são apenas removidos do banco quando o DataAdapter pega esses DataRows, ou pegando o DataSet passado como parâmetro no método Update do DataAdapter. (http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqldataadapter_methods.aspx)
Há muita vantagens nestas estrutura mais fragmentada. Recentemente fiz um formulário que tinha 3 nÃveis de registros aninhados em GridView. Com DataTables e DataRelation foi fácil fazer e manipular os dados, e dessa vez nem houve necessidade de usar DataAdapters, pois era só ReadOnly.
Tem que ter um pouco de paciência mesmo, ms no final vc vai ver que é fácil e tem muitas possibilidades. E de quebra, já vai se preparando pra aprender sobre ORMs, no caso do .Net o Entity Framework. Não vai querer outra vida.
Esse objetos têm responsabilidades bem definidas. Um DataTable não faz link direto com o banco de dados (acho que o Macoratti já até esc reveu sobre isso), ele é apenas representação de uma tabela que uma tabela ou query com campos limitados que o DataAdapter buscou no banco de dados. Repare que quem tem métodos para atualizar o banco de dados é o DataAdapter. Vc pode até mandar deletar registros (DataRows) do DataTable, eles são assinalados e ficam em cache e fisicamente não são excluÃdos di banco. Eles são apenas removidos do banco quando o DataAdapter pega esses DataRows, ou pegando o DataSet passado como parâmetro no método Update do DataAdapter. (http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqldataadapter_methods.aspx)
Há muita vantagens nestas estrutura mais fragmentada. Recentemente fiz um formulário que tinha 3 nÃveis de registros aninhados em GridView. Com DataTables e DataRelation foi fácil fazer e manipular os dados, e dessa vez nem houve necessidade de usar DataAdapters, pois era só ReadOnly.
Tem que ter um pouco de paciência mesmo, ms no final vc vai ver que é fácil e tem muitas possibilidades. E de quebra, já vai se preparando pra aprender sobre ORMs, no caso do .Net o Entity Framework. Não vai querer outra vida.
Tópico encerrado , respostas não são mais permitidas