MELHORAR DESEMPENHO DA APLICACAO
Boa tarde VBManÃacos!
Tenho uma aplicação pronta, que usa acesso à  Banco de Dados SQL, o programa roda perfeitamente, porém tem apresentado uma queda no desempenho na parte de abertura de recordsets e objetos connection.
Eu comecei a fazer essa aplicação há algum tempo, qdo não tinha muita "manha" do VB, porém, agora, comecei a descobrir o "caminho das pedras"...
Abro um recordset para cada tabela do sistema (mto newbie!!!), e isto tem caÃdo mto com o desempenho, tenho umas 15-20 tabelas, sendo que destas apenas 5 ou 6 são vitais, as outras são somente de manutenção de cadastros (inclusão, alteração, exclusão, etc...).
Pensei em abrir um recordset só para estas tabelas de cadastro, mas, não sei se iria dar certo. O usuário poderia abrir um formulário e ao abrir outro, dar erro de recordset aberto... ...há como contornar essa situação? Talvez restringindo a abertura deste formulários... ...sinceramente, não sei...
Como poderia minimizar o número de recordsets abertos, e melhorar o desempenho da aplicação, fechando recordsets ao fechar formulários ou algo do tipo?
Quaisquer sugestões são bem vindas!
Tenho uma aplicação pronta, que usa acesso à  Banco de Dados SQL, o programa roda perfeitamente, porém tem apresentado uma queda no desempenho na parte de abertura de recordsets e objetos connection.
Eu comecei a fazer essa aplicação há algum tempo, qdo não tinha muita "manha" do VB, porém, agora, comecei a descobrir o "caminho das pedras"...
Abro um recordset para cada tabela do sistema (mto newbie!!!), e isto tem caÃdo mto com o desempenho, tenho umas 15-20 tabelas, sendo que destas apenas 5 ou 6 são vitais, as outras são somente de manutenção de cadastros (inclusão, alteração, exclusão, etc...).
Pensei em abrir um recordset só para estas tabelas de cadastro, mas, não sei se iria dar certo. O usuário poderia abrir um formulário e ao abrir outro, dar erro de recordset aberto... ...há como contornar essa situação? Talvez restringindo a abertura deste formulários... ...sinceramente, não sei...
Como poderia minimizar o número de recordsets abertos, e melhorar o desempenho da aplicação, fechando recordsets ao fechar formulários ou algo do tipo?
Quaisquer sugestões são bem vindas!
Para evitar o conflito de Aberto coloque em toda rotina que acessar o BD:
If rs.State = 1 then rs.close
Assim, sempre verifica se está aberto e fecha se estiver.
Outra sugestão/opinião: Eu sempre detestei trabalhar com ADO Declarado em vez de Vinculado. Mas estou em um projeto que usa Declarado, apesar do trabalho gigantesco para atualizar texts e combos, é até "legal" o ADO Declarado.
Aqui usamos da seguinte forma: Uma declaração de conexão e 3 de recordset para todo o sistema (para o caso de ter que manter algo aberto enquanto verifica outra situação). E funciona muito bem, temos mais de 50 tabelas, todas essenciais, interligadas, etc. Nunca temos erros ou problemas por usar somente 3 recordset.
If rs.State = 1 then rs.close
Assim, sempre verifica se está aberto e fecha se estiver.
Outra sugestão/opinião: Eu sempre detestei trabalhar com ADO Declarado em vez de Vinculado. Mas estou em um projeto que usa Declarado, apesar do trabalho gigantesco para atualizar texts e combos, é até "legal" o ADO Declarado.
Aqui usamos da seguinte forma: Uma declaração de conexão e 3 de recordset para todo o sistema (para o caso de ter que manter algo aberto enquanto verifica outra situação). E funciona muito bem, temos mais de 50 tabelas, todas essenciais, interligadas, etc. Nunca temos erros ou problemas por usar somente 3 recordset.
Poxa...
Parabéns mesmo... 50 tabelas com 3 recordsets! Legal msm!
Mas, por exemplo, digamos que o usuários está numa tabela de cadastro de contas a pagar no registro X, e ele quer abrir o cadastro de contas a receber no registro Y simultaneamente... Ele teria q fechar a tabela de contas a pagar para abrir a tela de contas a receber...
Eu uso ado declarado tbem... Acho mto mais "nerd". Hehehehhehehehhe
Parabéns mesmo... 50 tabelas com 3 recordsets! Legal msm!
Mas, por exemplo, digamos que o usuários está numa tabela de cadastro de contas a pagar no registro X, e ele quer abrir o cadastro de contas a receber no registro Y simultaneamente... Ele teria q fechar a tabela de contas a pagar para abrir a tela de contas a receber...
Eu uso ado declarado tbem... Acho mto mais "nerd". Hehehehhehehehhe
desculpe a pergunta que pode parecer besta mais como eu to começando gostaria de saber qual a difereça de ADO declarado com o vinculado
é indiferente o numero de Tabelas com a quantidade de recordset. Tenho um projeto com 63 tabelas e só uso 1 recordset e 1 conection.Que são variaveis publicas.
Como Access não da suporte para um Cursor Dinamico ( o que pega inclusão, alteração e exclusão) não vejo necessidade de manter um cursor aberto.
E também acho ruim o "gatilho" If rs.State = 1 then rs.close , salvo se colocar isso no tratamento de erro. Pois vc dessa forma não se "preocupa" se o recordset esta ou não aberto e pode passar despercebido. Vc deve ter controle do recordset, não deve perder esse controle. Se abriu sempre feche.
Não vejo nenhum impedimento usando um recordset só. Faço da seguinte maneira, o usuario abriu o formulario então abro o recordset carrego o que tem que carregar fecho recordset. O Usuario abriu outro formulario então novamente abro e fecho recordset. Nunca mantenho recordset abertos, logo não uso nenhum componente do tipo DATA. Prefiro manter todo o controle do acesso ao banco na mão mesmo.
Um exemplo:
Numa tela listo todos os clientes cadastrados em uma ListView ( logo abro o recordset carrego a lista e fecho) normalmente coloco a chamada dessa rotina no Active do Form.
Então o usuario quer ver a ficha completa do cliente , ele da um duplo click na linha do listview, nesse evento do DuploClick e pego a chave primaria que já esta carregada na lista view ( normalmente é a primeira coluna onde coloco o tamanho igual a zero, logo esse coluna não é visualizada pelo usuario, visto que esse valor na maioria das vezes para ele é indiferente.)
Retornando, então pego o Id do cliente e passo esse valor para o form 2, o form que exibe a ficha. Pode fazer essa passagem de várias formas
1) seria colocando mais uma propriedade no form2 ( alterando a classe)
Então no form 1 ficaria +ou- assim
private Sub ListView_Duplo_Click()
Unload me
wtih form2
.id= listview..... ( não estou com o vb aqui , não me lembro da propriedade do listview que retorna os campos da linha selecionada)
.Show 1
end sub
2) Assim no evento Active do Form 2 chamo a rotina AbrirRegistro que é um Select para o valor do ID. Logo abro o recordeset carrego os dados fecho recordset. Sendo que essa consulta é somente leitura
4) Caso ele queira alterar os dados tem um botão pra isso que faz um select do cliente novamente ( Dessa vez com o cursor com bloqueio Otimista), e faço a alteração via ADO e fecho cursor.
A Aplicação é toda assim. Não mantenho de forma alguma cursores abertos "a toa' a espera de uma ação do usuario. E sim abro os cursores quando o usuário efetua uma ação. Dessa forma 1 unico recordset é suficiente independente do numero de tabelas.
Isso seria uma forma de se programar. Tem vários estilos, uma seria não trabalhar com recordset global e cada subrotina que vc acessa o banco criar , abrir e fechar o recordset dentro da propria rotina. E essa rotina receberia como parametro a variavel de conexão. Dessa forma vc estaria modularizando o seu projeto.
obs: Somente em casos extremos onde não consigo fazer o Select desejado ai faço uso de mais de 1 recordset, mas isso em subrotinas, para relatorios especificos. Seria um recordset temporario.
R: Primeiro não tem nada de besta.Bem o ADO vinculado seria um componente (OCX) que implementaram de forma a fazer uma abstração do ADO declarado. Pois no código desse componente esta lá o ADO declarado. Isso seria uma abstração do ADO, onde vc não ve o codigo do ADO e somente os metodos e propriedades do Componentes. Eu não uso por vários motivos:
1) Vc fica condicionado ao componente, assim vc não sabe ADO e sim usar o componente X que usa ADO.
2) Normalmente esses componentes mantém o cursor aberto, o que ocasiona num custo maior ao servidor e no caso do Access deixa o banco mais vulneravel.
3) Vc se limita aos metodos que foram implementados. E as vezes eles não são suficientes ai começa os gatilhos para tudo que é lado.
O Bom do lado do uso de componentes Data é a facilidade, vc praticamente não digita nenhum código, basta colocar um Data Control, dar o caminho do banco de qual tabela vc quer, lincar os textbox no campo que quer e a atualização, exclusão e inclusão é bem facil.Logo ganha em eficiencia na codificação. Mas avaliando os pos e os contras fico com o ADO declarado.
Espero ter ajudado.
Como Access não da suporte para um Cursor Dinamico ( o que pega inclusão, alteração e exclusão) não vejo necessidade de manter um cursor aberto.
E também acho ruim o "gatilho" If rs.State = 1 then rs.close , salvo se colocar isso no tratamento de erro. Pois vc dessa forma não se "preocupa" se o recordset esta ou não aberto e pode passar despercebido. Vc deve ter controle do recordset, não deve perder esse controle. Se abriu sempre feche.
Citação:Pensei em abrir um recordset só para estas tabelas de cadastro, mas, não sei se iria dar certo. O usuário poderia abrir um formulário e ao abrir outro, dar erro de recordset aberto... ...há como contornar essa situação? Talvez restringindo a abertura deste formulários... ...sinceramente, não sei...
Não vejo nenhum impedimento usando um recordset só. Faço da seguinte maneira, o usuario abriu o formulario então abro o recordset carrego o que tem que carregar fecho recordset. O Usuario abriu outro formulario então novamente abro e fecho recordset. Nunca mantenho recordset abertos, logo não uso nenhum componente do tipo DATA. Prefiro manter todo o controle do acesso ao banco na mão mesmo.
Um exemplo:
Numa tela listo todos os clientes cadastrados em uma ListView ( logo abro o recordset carrego a lista e fecho) normalmente coloco a chamada dessa rotina no Active do Form.
Então o usuario quer ver a ficha completa do cliente , ele da um duplo click na linha do listview, nesse evento do DuploClick e pego a chave primaria que já esta carregada na lista view ( normalmente é a primeira coluna onde coloco o tamanho igual a zero, logo esse coluna não é visualizada pelo usuario, visto que esse valor na maioria das vezes para ele é indiferente.)
Retornando, então pego o Id do cliente e passo esse valor para o form 2, o form que exibe a ficha. Pode fazer essa passagem de várias formas
1) seria colocando mais uma propriedade no form2 ( alterando a classe)
Então no form 1 ficaria +ou- assim
private Sub ListView_Duplo_Click()
Unload me
wtih form2
.id= listview..... ( não estou com o vb aqui , não me lembro da propriedade do listview que retorna os campos da linha selecionada)
.Show 1
end sub
2) Assim no evento Active do Form 2 chamo a rotina AbrirRegistro que é um Select para o valor do ID. Logo abro o recordeset carrego os dados fecho recordset. Sendo que essa consulta é somente leitura
4) Caso ele queira alterar os dados tem um botão pra isso que faz um select do cliente novamente ( Dessa vez com o cursor com bloqueio Otimista), e faço a alteração via ADO e fecho cursor.
A Aplicação é toda assim. Não mantenho de forma alguma cursores abertos "a toa' a espera de uma ação do usuario. E sim abro os cursores quando o usuário efetua uma ação. Dessa forma 1 unico recordset é suficiente independente do numero de tabelas.
Isso seria uma forma de se programar. Tem vários estilos, uma seria não trabalhar com recordset global e cada subrotina que vc acessa o banco criar , abrir e fechar o recordset dentro da propria rotina. E essa rotina receberia como parametro a variavel de conexão. Dessa forma vc estaria modularizando o seu projeto.
obs: Somente em casos extremos onde não consigo fazer o Select desejado ai faço uso de mais de 1 recordset, mas isso em subrotinas, para relatorios especificos. Seria um recordset temporario.
Citação:desculpe a pergunta que pode parecer besta mais como eu to começando gostaria de saber qual a difereça de ADO declarado com o vinculado
R: Primeiro não tem nada de besta.Bem o ADO vinculado seria um componente (OCX) que implementaram de forma a fazer uma abstração do ADO declarado. Pois no código desse componente esta lá o ADO declarado. Isso seria uma abstração do ADO, onde vc não ve o codigo do ADO e somente os metodos e propriedades do Componentes. Eu não uso por vários motivos:
1) Vc fica condicionado ao componente, assim vc não sabe ADO e sim usar o componente X que usa ADO.
2) Normalmente esses componentes mantém o cursor aberto, o que ocasiona num custo maior ao servidor e no caso do Access deixa o banco mais vulneravel.
3) Vc se limita aos metodos que foram implementados. E as vezes eles não são suficientes ai começa os gatilhos para tudo que é lado.
O Bom do lado do uso de componentes Data é a facilidade, vc praticamente não digita nenhum código, basta colocar um Data Control, dar o caminho do banco de qual tabela vc quer, lincar os textbox no campo que quer e a atualização, exclusão e inclusão é bem facil.Logo ganha em eficiencia na codificação. Mas avaliando os pos e os contras fico com o ADO declarado.
Espero ter ajudado.
Entendi como funciona...
Vou tentar seguir as sugestões apresentadas pelo RENATOMATTOS e o FGSANTOS para tentar acelerar o desempenho da minha aplicação.
Se tiver algum problema, eu mando uma mensagem interna pra vcs!
Valeu!
Vou tentar seguir as sugestões apresentadas pelo RENATOMATTOS e o FGSANTOS para tentar acelerar o desempenho da minha aplicação.
Se tiver algum problema, eu mando uma mensagem interna pra vcs!
Valeu!
Tópico encerrado , respostas não são mais permitidas