ADODC
Vejam so a minmha duvida:
Eu sempre uso a abertura de Recordset através de codigos (na unha) para ter mais controle e sempre ter o cuidado de haver somente uma conexao para todos os recordset envolvidos.
Mas quando necessito de um DATAGRID eu uso o ADO Data Control (Adodc) para vincula-lo ao grid.
Porém, vem a duvida:
a)Se no meu Formulario eu abro uma conexao ao banco de dados (Connection) e um Recordset (tabela de produtos) através dos codigos e depois uso um Adodc para abrir outros Recordset (tabela de grupos e tabela de subgrupos). Por acaso, sempre que eu abro um Adodc nao é aberto uma nova conexao tambem? Se no mesmo formulario eu tiver dois Adodc irá haver Tres conexoes ao banco de dados abertas (uma via codigo e duas via Adodc)?
b) Se isto acontece, como fazer para que os Adodc use a conexao ja aberta via codigo (Connection) ?
c)Qual é mais eficiente? o Adodc ou Data Environment?
Cordialmente
Lionardo
Eu sempre uso a abertura de Recordset através de codigos (na unha) para ter mais controle e sempre ter o cuidado de haver somente uma conexao para todos os recordset envolvidos.
Mas quando necessito de um DATAGRID eu uso o ADO Data Control (Adodc) para vincula-lo ao grid.
Porém, vem a duvida:
a)Se no meu Formulario eu abro uma conexao ao banco de dados (Connection) e um Recordset (tabela de produtos) através dos codigos e depois uso um Adodc para abrir outros Recordset (tabela de grupos e tabela de subgrupos). Por acaso, sempre que eu abro um Adodc nao é aberto uma nova conexao tambem? Se no mesmo formulario eu tiver dois Adodc irá haver Tres conexoes ao banco de dados abertas (uma via codigo e duas via Adodc)?
b) Se isto acontece, como fazer para que os Adodc use a conexao ja aberta via codigo (Connection) ?
c)Qual é mais eficiente? o Adodc ou Data Environment?
Cordialmente
Lionardo
Bem, eu não uso nenhum deles, para colocar os dados no Datagrid, crio o recordset e coloco
set datagrid1.datasource = meurs
datagrid1.refresh
Pelo que vi o Adodc, cria sua prórpria conexão com o banco e não há nada que possamos fazer. Alguém me corrija se estiver errado.
Quanto ao melhor método, aconselho a usar via código
set datagrid1.datasource = meurs
datagrid1.refresh
Pelo que vi o Adodc, cria sua prórpria conexão com o banco e não há nada que possamos fazer. Alguém me corrija se estiver errado.
Quanto ao melhor método, aconselho a usar via código
Qual é mais eficiente? o Adodc ou Data Environment?
MARCOSA, eu usei este seu exemplo e nao funcionou. Voce poderia explica-lo melhor? Por acaso o Recordset que voce cria nao é atraves do ADODC?
1º - a
Os ADODC usam conexão própria. Assim, alguns formulários que eu já tive de lidar, usavam 15 ADODC e mais uma conexão "pública" (outra besteira de se fazer), num total de 16 conexões diferentes, "penduradas" no servidor ao mesmo tempo, para fazer uma só tarefa.
1Âê - b
Para que os ADODC utilizem a conexão "pública", você deve passá-la á propriedade ActiveConnection do objeto Recordset do controle ADODC. Mas acho que é desnecessário dizer que isso só pode ser feito após a criação desse Recordset, o que significa que a conexão primária do ADODC precisa ser feita. Isso quer dizer que, num primeiro momento, o controle vai usar a sua própria conexão, de qualquer forma.
1º - c
Ambos possuem o mesmo grau de eficiência. Só que possuem utilizações bastante distintas entre sÃ. Um DataEnvironment é, além de um conjunto de objetos de acesso á dados, uma interface gráfica para gerenciamento que consome e fornece dados. Sua utilização, portanto, é bem mais ampla. Mas os DE também possuem conexão própia com o banco de dados, e que é uma conexão pública para o projeto. Cada processo realizado se torna disponÃvel á todo o projeto, assim que se torna disponÃvel ao DataEnvironment. Por conta disso, há situações onde o programador pode ter o DataEnvironment como parceiro, mas há aquelas onde o programador vira refém dele.
Como no caso dos ADODC, você pode usar vários DataEnvironment em seu projeto, um para cada banco de dados, ou mais de um para o mesmo banco, como desejar. Mas bem diferente de um ADODC, os DataEnvironment podem manter diversos objetos de acesso á dados sob a forma de objetos ADODB.Command, o que permite uma lide integrada com diversas tabelas e consultas simultaneamente.
Nenhum dos dois, contudo, é necessário. Seu projeto pode fazer tudo o que seja necessário sem usar nenhum deles, mas apenas código simples, em módulos, classes e formulários.
Os ADODC usam conexão própria. Assim, alguns formulários que eu já tive de lidar, usavam 15 ADODC e mais uma conexão "pública" (outra besteira de se fazer), num total de 16 conexões diferentes, "penduradas" no servidor ao mesmo tempo, para fazer uma só tarefa.
1Âê - b
Para que os ADODC utilizem a conexão "pública", você deve passá-la á propriedade ActiveConnection do objeto Recordset do controle ADODC. Mas acho que é desnecessário dizer que isso só pode ser feito após a criação desse Recordset, o que significa que a conexão primária do ADODC precisa ser feita. Isso quer dizer que, num primeiro momento, o controle vai usar a sua própria conexão, de qualquer forma.
1º - c
Ambos possuem o mesmo grau de eficiência. Só que possuem utilizações bastante distintas entre sÃ. Um DataEnvironment é, além de um conjunto de objetos de acesso á dados, uma interface gráfica para gerenciamento que consome e fornece dados. Sua utilização, portanto, é bem mais ampla. Mas os DE também possuem conexão própia com o banco de dados, e que é uma conexão pública para o projeto. Cada processo realizado se torna disponÃvel á todo o projeto, assim que se torna disponÃvel ao DataEnvironment. Por conta disso, há situações onde o programador pode ter o DataEnvironment como parceiro, mas há aquelas onde o programador vira refém dele.
Como no caso dos ADODC, você pode usar vários DataEnvironment em seu projeto, um para cada banco de dados, ou mais de um para o mesmo banco, como desejar. Mas bem diferente de um ADODC, os DataEnvironment podem manter diversos objetos de acesso á dados sob a forma de objetos ADODB.Command, o que permite uma lide integrada com diversas tabelas e consultas simultaneamente.
Nenhum dos dois, contudo, é necessário. Seu projeto pode fazer tudo o que seja necessário sem usar nenhum deles, mas apenas código simples, em módulos, classes e formulários.
Tópico encerrado , respostas não são mais permitidas