DEVE TER 1 CONEXAO ADO PARA CADA TABELA ?
Nos meus sistemas crio uma Objeto Conexão e um Objeto Recordset para cada tabela, quero saber se posso ter uma única conexão para todos os Recordset ?
pode Sim se as RecordSet(s) estiverem no mesmo banco referenciado na
conexão.
se estiver usando ADO.
Exemplo:
Dim Cnn As New ADODB.Connection
Dim Rst1 As New ADODB.RecordSet
Dim Rst2 As New ADODB.RecordSet
Set Rst1.ActiveConnection = Cnn
Set Rst2.ActiveConnection = Cnn
Rst2.Open "Select * From TB_1", , adDynamic,adOpmistic
Rst1.Open "Select * From TB_2", , adDynamic,adOpmistic
é isso ?
conexão.
se estiver usando ADO.
Exemplo:
Dim Cnn As New ADODB.Connection
Dim Rst1 As New ADODB.RecordSet
Dim Rst2 As New ADODB.RecordSet
Set Rst1.ActiveConnection = Cnn
Set Rst2.ActiveConnection = Cnn
Rst2.Open "Select * From TB_1", , adDynamic,adOpmistic
Rst1.Open "Select * From TB_2", , adDynamic,adOpmistic
é isso ?
Sim. Não tem necessidade de criar uma variavel conection e Recordset para cada tabela, pois torna o sistema ineficiente.é caro para o servidor manter um objeto conecion principalmente.
Basta utilizar uma unica variavel Conection e uma unica variavel Recordset.
Basta utilizar uma unica variavel Conection e uma unica variavel Recordset.
Eu utilizo uma connection e crio 3 recordset para trabalho. Nunca de esqueça de fechá-la após utilizar, para evitar conflitos e erros.
declare uma variável de conexão em um módulo como sendo:
Global [sua conexão] As New ADODB.Connection
Lembre-se, dúvida respondida = tópico encerrado
Global [sua conexão] As New ADODB.Connection
Lembre-se, dúvida respondida = tópico encerrado
Bem, como vocês disseram, posso ter apenas uma variavel de conection e uma de recordset, mas e quando eu tenho que abrir duas ou mais tabelas simultaneamentes ? ai tenho que criar uma variavel recordset para cada tabela ?
é tipo vc cria uma variavel de conecção por bd e um recordset por tabela q vc utilizar.
Bem sobre abrir 2 tabelas ou mais simultaneamente. Creio que seria para fazer relacionamento entre elas, se não for por esse motivo não seria simultaneo Certo?
Bem se for para relacionamento vc faz isso via SQL em um unico recordset. O que é muito mais facil.
Tive dois casos em que não consegui de jeito nenhum fazer o SQL, então levei umas horas a mais para fazer o relacionamento na mão. O que não é nada simples pois na verdade envolve conjuntos onde vc aplica união e interseção. Mesmo assim optei por um unico Recordset, com o uso de Collection, onde carraga a consulta num Collection ( Um conjunto) , depois carrega outra consulta em outro Collection ( outro conjunto) ai trabalhei somente com os collection para fazer as uniões e interseções. Visto que é um código chato e ineficiente seria perigoso por demais ( quanto mai sno Access) fazer isso usando 2 recordset.
Bem se for para relacionamento vc faz isso via SQL em um unico recordset. O que é muito mais facil.
Tive dois casos em que não consegui de jeito nenhum fazer o SQL, então levei umas horas a mais para fazer o relacionamento na mão. O que não é nada simples pois na verdade envolve conjuntos onde vc aplica união e interseção. Mesmo assim optei por um unico Recordset, com o uso de Collection, onde carraga a consulta num Collection ( Um conjunto) , depois carrega outra consulta em outro Collection ( outro conjunto) ai trabalhei somente com os collection para fazer as uniões e interseções. Visto que é um código chato e ineficiente seria perigoso por demais ( quanto mai sno Access) fazer isso usando 2 recordset.
Com apenas um Connection você pode invocar quaisquer tabelas, sp ou views que desejar, e, caso funcionalize esse objeto, até em bancos de dados e engines diferentes, na mesma aplicação.
Já as consultas em tabelas ou views, estas, não há muito o que fazer, se é necessário abrir duas ou mais simultaneamente.
é, sim, necessária a criação de uma variável ADODB.Recordset diferente para cada tabela quse seja aberta de modo simultà ¢neo, instanciar essa variável com a conexão e o objeto Recordset, utilizar, encerrar o objeto com um Close e limpar a memória usada pela variável com um Set oRecordset = Nothing.
Mas isto APENAS no caso de duas tabelas/views serem requisitadas de forma simultà ¢nea.
Caso seja necessário, por exemplo, mostrar em uma grade de dados, o Departamento de um Usuário cadastrado, sendo que existam duas tabelas distintas, uma para os Departamentos e outra para os Usuários, um único objeto Recordset resolve o problema sem nenhum esforço. Deve, contudo, haver uma ligação (relacionamento) entre as tabelas, mesmo que seja apenas implÃcito, ou seja, sem que você tenha relacionado efetivamente as tabelas pelo MS-Access ou criado objetos Relation para anexar ao BD.
O Recordset, neste caso, teria na propriedade Source uma sintaxe similar á: "SELECT A.NOME AS USUARIO, B.DESCRICAO AS DEPARTAMENTO FROM TB_USUARIOS A, TB_DEPARTAMENTOS B WHERE A.ID_DEPARTAMENTO = B.ID_DEARTAMENTO".
A sintaxe acima exposta é funcional para a linguagem SQL do MS-Access, bem como do Oracle e do SQL-Server, mas nas versões mais atuais, os JOINT TABLES são realizados mais eficientemente por cláusulas como "...INNER JOIN TABELA B ON A.CAMPO = B.CAMPO...", "...LEFT JOIN TABELA B ON A.CAMPO = B.CAMPO...", "...OUTER JOIN TABELA B ON A.CAMPO = B.CAMPO..." etc. Apesar disto, a sintaxe "primitiva" permanece funcional.
Voltando ao ponto, sempre que possÃvel, utilize apenas um objeto Connection em toda a aplicação; Utilize tantos objetos Recordset quanto sejam as tabelas simultà ¢neas necessárias para a tarefa ou processo; ENCERRE e esvazie a memória de TODOS os objetos, quaisquer que sejam eles, após sua utilização. De preferência, providencie que a própria conexão seja desabilitada durante perÃodos de inatividade pré-definidos, retomando a mesma quando do inÃcio das atividades; Evite ao máximo a utilização de controles adodc e DataControl, pois eles mantém conexões paralelas; Ao encerrar o uso de um formulário, principalmente se ligado á dados, não utilize apenas o Unload, mas também atribua um Nothing ao formulário após sua descarga; Mantenha suas variáveis públicas (aquelas que devem ser "enxergadas" por quaisquer módulos, formulários, controles, etc) em módulos BAS exclusivos para essa finalidade; Mantenha sempre as declarações de variáveis privadas ("PRIVATE") para aquelas variáveis que só serão utilizadas em um Formulário ou módulo.
Estas são algumas "Top Keys" para que a sua aplicação se mantenha mais afinada e de mais fácil manutenção.
Com certeza, muitos colegas aqui no site poderiam contribuir com mais.
Já as consultas em tabelas ou views, estas, não há muito o que fazer, se é necessário abrir duas ou mais simultaneamente.
é, sim, necessária a criação de uma variável ADODB.Recordset diferente para cada tabela quse seja aberta de modo simultà ¢neo, instanciar essa variável com a conexão e o objeto Recordset, utilizar, encerrar o objeto com um Close e limpar a memória usada pela variável com um Set oRecordset = Nothing.
Mas isto APENAS no caso de duas tabelas/views serem requisitadas de forma simultà ¢nea.
Caso seja necessário, por exemplo, mostrar em uma grade de dados, o Departamento de um Usuário cadastrado, sendo que existam duas tabelas distintas, uma para os Departamentos e outra para os Usuários, um único objeto Recordset resolve o problema sem nenhum esforço. Deve, contudo, haver uma ligação (relacionamento) entre as tabelas, mesmo que seja apenas implÃcito, ou seja, sem que você tenha relacionado efetivamente as tabelas pelo MS-Access ou criado objetos Relation para anexar ao BD.
O Recordset, neste caso, teria na propriedade Source uma sintaxe similar á: "SELECT A.NOME AS USUARIO, B.DESCRICAO AS DEPARTAMENTO FROM TB_USUARIOS A, TB_DEPARTAMENTOS B WHERE A.ID_DEPARTAMENTO = B.ID_DEARTAMENTO".
A sintaxe acima exposta é funcional para a linguagem SQL do MS-Access, bem como do Oracle e do SQL-Server, mas nas versões mais atuais, os JOINT TABLES são realizados mais eficientemente por cláusulas como "...INNER JOIN TABELA B ON A.CAMPO = B.CAMPO...", "...LEFT JOIN TABELA B ON A.CAMPO = B.CAMPO...", "...OUTER JOIN TABELA B ON A.CAMPO = B.CAMPO..." etc. Apesar disto, a sintaxe "primitiva" permanece funcional.
Voltando ao ponto, sempre que possÃvel, utilize apenas um objeto Connection em toda a aplicação; Utilize tantos objetos Recordset quanto sejam as tabelas simultà ¢neas necessárias para a tarefa ou processo; ENCERRE e esvazie a memória de TODOS os objetos, quaisquer que sejam eles, após sua utilização. De preferência, providencie que a própria conexão seja desabilitada durante perÃodos de inatividade pré-definidos, retomando a mesma quando do inÃcio das atividades; Evite ao máximo a utilização de controles adodc e DataControl, pois eles mantém conexões paralelas; Ao encerrar o uso de um formulário, principalmente se ligado á dados, não utilize apenas o Unload, mas também atribua um Nothing ao formulário após sua descarga; Mantenha suas variáveis públicas (aquelas que devem ser "enxergadas" por quaisquer módulos, formulários, controles, etc) em módulos BAS exclusivos para essa finalidade; Mantenha sempre as declarações de variáveis privadas ("PRIVATE") para aquelas variáveis que só serão utilizadas em um Formulário ou módulo.
Estas são algumas "Top Keys" para que a sua aplicação se mantenha mais afinada e de mais fácil manutenção.
Com certeza, muitos colegas aqui no site poderiam contribuir com mais.
Tópico encerrado , respostas não são mais permitidas