OPINIAO FECHAR/ABRIR BANCO DE DADOS
é realmente existem alguns detalhes básicos, o colega Luiz Herreira exclareceu de forma bem didática o assunto, porém realmente, uma má programação, uma rede mal estruturada pode colocar o desempenho em baixa, abrir e fechar torna sim o sistema mais lento, mas as vezes o que nós programadores notamos o usuário final não nota, pois depois de comecei a programar, passei a prestar mais atenção em mercados mini mercados, etc e percebi alguns sistemas muito lentos, porém quando perguntei se era bom o usuário sempre diz ele é ótimo, o ponto de vista muda muito.
Qdo passei do DAO para o ADO lembro-me de ter lido que a conexão poderia ser deixada aberta. Mas o recorset, abre, usa, fecha e descarta. A partir dai, passei a abrir a conexão logo no sub-main e as recordsets somente no ponto que iria usar.
Mas principalmente, acho que vai do tipo de aplicação que está sendo desenvolvida. Se é aplicação local,ou intranet, com poucos usuários (até uns 5) vc não irá encontrar problema em deixar a conexão aberta. Agora se vc vai ter muito acesso concorrente, independente do SGBD estar na net ou intranet, acho que seria melhor fechar a conexão. Com isso vc garante um confiabilidade maior ao SGBD evitando corrupção das informações e integridade do banco. Além de liberar recursos!
Mas principalmente, acho que vai do tipo de aplicação que está sendo desenvolvida. Se é aplicação local,ou intranet, com poucos usuários (até uns 5) vc não irá encontrar problema em deixar a conexão aberta. Agora se vc vai ter muito acesso concorrente, independente do SGBD estar na net ou intranet, acho que seria melhor fechar a conexão. Com isso vc garante um confiabilidade maior ao SGBD evitando corrupção das informações e integridade do banco. Além de liberar recursos!
Concordo com o LuÃs Herrera.
Uma coisa é certa, com Access, é abrir a conexão, trabalhar com os dados e matar em seguida. Tive melhoras significativas num sistema que vivia corrompendo. E mesmo num SGBD, dependendo da quantidade de terminais acessando o Servidor, conexões abertas podem ser prejudiciais, porque consome recurso do Servidor, pois o usuário pode deixar a aplicação aberta e sair pra almoçar, ou editar um documento etc.
Há situações que possamos deixar a conexão aberta em um intervalo um pouco maior, como por exemplo um PDV de um hipermercado, onde a busca pelos produtos ocorrem num pequeno intervalo de tempo. Eu deixaria aberta a conexão enquanto o cupom estivesse em aberto, não abriria a conexão pra cada busca de produto.
Uma coisa é certa, com Access, é abrir a conexão, trabalhar com os dados e matar em seguida. Tive melhoras significativas num sistema que vivia corrompendo. E mesmo num SGBD, dependendo da quantidade de terminais acessando o Servidor, conexões abertas podem ser prejudiciais, porque consome recurso do Servidor, pois o usuário pode deixar a aplicação aberta e sair pra almoçar, ou editar um documento etc.
Há situações que possamos deixar a conexão aberta em um intervalo um pouco maior, como por exemplo um PDV de um hipermercado, onde a busca pelos produtos ocorrem num pequeno intervalo de tempo. Eu deixaria aberta a conexão enquanto o cupom estivesse em aberto, não abriria a conexão pra cada busca de produto.
Perfeito!!!!
Marcelo esse é um ponto importante mesmo, o ponto de vista do cliente, já que o nosso [Ô]Deve[Ô] ser sempre mais apurado e exigente, assim o cliente geralmente ficará satisfeito, pois exigimos mais que eles. Agora quando o cidadão teima em ter um 386 com Windows 98 (primeira edição) e quer um ERP rodando, só rindo.
Leandro bem lembrado. Sim cada caso é um caso e em informática nunca existirá uma receita de bolo ideal. Uma frente de caixa com leitor de código de barras deve ficar com a conexão aberta até finalizar o cupom, é muito mais produtivo. Porém se forem 40 caixas com várias filiais acessando um único servidor centralizado, também não [Ô]rolaria[Ô] muito bem. O ideal seria dividir cada filial com um servidor local e depois atualizar tudo no central em batch por exemplo.
Alguem aqui no VBM já disse uma vez ter um sistema de supermercado com 200 caixas em MS Access rodando muito bem, não lembro quem foi. Certamente teve muito cuidade com a codificação, como eu tenho, mas certamente isso continua sendo um risco também, pois em algum momento algo pode dar errado, como já deu, uma faxineira desligar o servidor com a vassoura, no meio de um balanço de estoque. Foi tudo pro beleleu. Sorte que havia um backup do dia anterior e só se perdeu o movimento do dia, que teve de ser refeito.
Marcelo esse é um ponto importante mesmo, o ponto de vista do cliente, já que o nosso [Ô]Deve[Ô] ser sempre mais apurado e exigente, assim o cliente geralmente ficará satisfeito, pois exigimos mais que eles. Agora quando o cidadão teima em ter um 386 com Windows 98 (primeira edição) e quer um ERP rodando, só rindo.
Leandro bem lembrado. Sim cada caso é um caso e em informática nunca existirá uma receita de bolo ideal. Uma frente de caixa com leitor de código de barras deve ficar com a conexão aberta até finalizar o cupom, é muito mais produtivo. Porém se forem 40 caixas com várias filiais acessando um único servidor centralizado, também não [Ô]rolaria[Ô] muito bem. O ideal seria dividir cada filial com um servidor local e depois atualizar tudo no central em batch por exemplo.
Alguem aqui no VBM já disse uma vez ter um sistema de supermercado com 200 caixas em MS Access rodando muito bem, não lembro quem foi. Certamente teve muito cuidade com a codificação, como eu tenho, mas certamente isso continua sendo um risco também, pois em algum momento algo pode dar errado, como já deu, uma faxineira desligar o servidor com a vassoura, no meio de um balanço de estoque. Foi tudo pro beleleu. Sorte que havia um backup do dia anterior e só se perdeu o movimento do dia, que teve de ser refeito.
Tópico encerrado , respostas não são mais permitidas