OPINIAO FECHAR/ABRIR BANCO DE DADOS
Boa noite pessoal, aqui, estou vindo mais uma vez para ter opinião de voces no quisito abertura / fechamento de banco de dados, vejam só, eu atualmente trabalho com o banco aberto a todo tempo, e fecho os recordsets apos utilizalos, ou seja, uso o recordset apenas para preencher os controles, e descarto eles logo em seguida.. rs.close, set rs=nothing, para deixar um código mais seguro no quisito de corrompimento de banco/melhor operaçao com tabelas, e banco estava pensando a todo momento que obtivesse a informação que desejo, preencher os controles, etc, eu descartar os recordsets e exterminar a conexao com o banco, até o momento em que precisar usa-la novamente, como por exemplo, ao gravar uma informacao, ou consultar algo, tipo..
conexao aberta
set myrs = new adodb.recordset
myrs.open[Ô]select .... [Ô],conexao, ado....
apos o processamento..
myrs.close
set myrs=nothing
conexao fechada
Agora gostaria de compartilhar com voces o seguinte.. é lógico, obvio que vou ter muito trabalho ao ficar abrindo , fechando.. etc, mas em compensação.. se torna um codigo muito mais seguro.. o que voces acham????
conexao aberta
set myrs = new adodb.recordset
myrs.open[Ô]select .... [Ô],conexao, ado....
apos o processamento..
myrs.close
set myrs=nothing
conexao fechada
Agora gostaria de compartilhar com voces o seguinte.. é lógico, obvio que vou ter muito trabalho ao ficar abrindo , fechando.. etc, mas em compensação.. se torna um codigo muito mais seguro.. o que voces acham????
eu tbem mato os rs e deixo a cnn aberta. até o momento não tive problemas...acho q fechar a conexão e abrir para usar fica mesmo mais seguro, agora tem q ver se não fica lento...
pois é Edson, ai que esta o problema, e o grande motivo de eu abrir o topico, será que nao fica lento.. mas contando que.. como trabalho 90% com procedure.. o tempo de resposta nao fica taoo lento assim, como se fosse fazer tudo na ide.. mas sera que alguem mais opina?
XXXAngelsXXX Me ajuda la no meu tópico?!
bom eu fiz um teste, e abrindo e fechando a conexão o tempo todo, o processo de consulta ficava muito lento
então agora eu abro a conexão no load do form principal e fecho no unload do mesmo
os recordsets eu descarto isso não influencia, mesmo porque assim não corro o risco de esquecer algum deles abertos.
estou partilhando minha experiencia, pode até haver alguma outra forma, mas usando desta forma melhorei muito o desempenho do meu software.
então agora eu abro a conexão no load do form principal e fecho no unload do mesmo
os recordsets eu descarto isso não influencia, mesmo porque assim não corro o risco de esquecer algum deles abertos.
estou partilhando minha experiencia, pode até haver alguma outra forma, mas usando desta forma melhorei muito o desempenho do meu software.
Também abro a conexão no Load e fecho no Unload do form principal.
Tenho um sistema que possui banco local em Access e acessa um banco remoto, nesse caso do banco remoto eu abro a conexão, os recordsets, fecho-os depois e por último fecho a conexão com o banco remoto
Tenho um sistema que possui banco local em Access e acessa um banco remoto, nesse caso do banco remoto eu abro a conexão, os recordsets, fecho-os depois e por último fecho a conexão com o banco remoto
Citação:Beleza, então o negócio é em cada load do form abrir a conexao.. e na medida que for sendo necessario abrir os recordset, e no unload de cada form, eu destruo a conexao.. é isso que os companheiros fazem ne.. pois eu startava a conexao no sub_main e fechava no unload do form principal, quando iria sair do sistema definitivamente, aqui outra coisa, eu procurei aqui e nao achei a contento o codigo, o meu codigo nao funciona mmmuito bem, preciso destruir todos objetos que estiverem abertos, e todos os rs se por ventura tiver aberto quando saio do sistema.. quem vai ajudar.. rsrs..:
Também abro a conexão no Load e fecho no Unload do form principal.
Tenho um sistema que possui banco local em Access e acessa um banco remoto, nesse caso do banco remoto eu abro a conexão, os recordsets, fecho-os depois e por último fecho a conexão com o banco remoto
Eu abro e fecho a conexão a cada momento que precisar, e ja fiz muitos testes e não vi diferença de desempenho em relação a manter a conexão aberta.
Obs: uso firebird.
Obs: uso firebird.
Vejam esse link: http://www.macoratti.net/09/06/vbn_upc.htm sobre pool de conexões
NA MINHA OPINIÃO
Abrir e fechar com certeza deixa mais lento ja que vc perde o tempo que o sistema leva para logar no banco e estabelecer a conexão para ai sim depois executar o record set .Não podemos deixar de levar em consideração que a base pode estar sendo acessada na internet e cada x que abrir e fechar ja vai causar mais trafego.
Abrir e fechar com certeza deixa mais lento ja que vc perde o tempo que o sistema leva para logar no banco e estabelecer a conexão para ai sim depois executar o record set .Não podemos deixar de levar em consideração que a base pode estar sendo acessada na internet e cada x que abrir e fechar ja vai causar mais trafego.
Amigos vamos separar 3 coisas aqui que posso falar isso por experiência própria em vários clientes.
1- Hardware
2- Programação
3- Tipo de Conexão
Bem o artigo do Maroratti aborda ADO.Net, mas a pergutna veio no forum VB6 então não é válida aqui.
O Windows (versões a partir do XP) faz algo parecido com o Pool de conexões, mas para todos os recuros dos aplicativos executados. Se testarem verão que sempre será mais demorado a primeira execução de qualquer aplicativo, pois estará carregando tudo. Porém se vocês fecharem o aplicativo e abrirem novamente, verão que ele abrirá muito mais rápido quase como se já estivesse aberto, desde que seu hardware não seja uma carroça. Isso acontece em função do Windows preservar os recuros em memória para uso posterior. O mesmo acontece com as conexões a banco de dados.
Quando comecei a programar, este foi um assunto que pesquisei muito e segundo especialistas em banco de dados (norte americanos), um conceito básico no uso compartilhado de banco de dados em redes (relacionais) é sem dúvida alguma abrir, usar e fechar o quando antes a conexão. Não só para liberar os recuros, mas como segurança do banco, mesmo que seja um SGDB.
Depois que li sobre isso e mudei, não abro mão desta forma de programação.
Não entrando no mérito da questão, pois não sou especialista, vejo frequentemente gente reclamando de problemas com os bancos de dados em muitos lugares, e isso envolve SQL Server, Oracle etc... Tive um cliente que usava meu sistema com Access (200 funcionários) e nuca teve problemas, já o outro ERP em SQL Server corrompia 2 vezes por semana no mÃnimo e vivia reclamando. O pessoal devia ter feito uma programação que Gambiarra seria luxo.
Na maioria das vezes podem ter certeza que é culpa de má programação e também conexões abertas.
Meu sistema já foi colocado a prova várias vezes por empresas de porte. A última com um cliente que trabalho a um anos, 1.500 funcionários, com cerca de 800 acessando constantemente o sistema. Então vamos lá. O programa é em VB6, MSAccess, ADO 2.6. A conexão e aberta e fechada sempre o mais rápido possÃvel.
Baseado num cenário destes, 100% iriam dizer que isso ficaria uma carroça. Não há nenhuma reclamação de lentidão, inclusive há várias unidades remotas acessando o mesmo servidor via Teminal Server. Tudo funciona perfeitamente.
Então se a codificação for bem feita, o cabeamento da empresa e o hardware for bem dimensionado, não há problemas de lentidão. A abertura e fechamento é rápido o que demora são as consultas, estas devem ser otimizadas. Agora realmente se o servidor for inadequado, memória limitada, cabeamento precário, configuração do SO equivocada e programação deficiente, será um problema atrás do outro.
Nota: Já tive problemas de lentidão que não tinham qualquer relação com meu aplicativo, os vilões eram outros e depois de detectados, tudo funcionou perfeitamente ex. de problemas:
Firewall ZoneAlarme
Antivirus Norton e MCaffee
Servidores mal configurados
1- Hardware
2- Programação
3- Tipo de Conexão
Bem o artigo do Maroratti aborda ADO.Net, mas a pergutna veio no forum VB6 então não é válida aqui.
O Windows (versões a partir do XP) faz algo parecido com o Pool de conexões, mas para todos os recuros dos aplicativos executados. Se testarem verão que sempre será mais demorado a primeira execução de qualquer aplicativo, pois estará carregando tudo. Porém se vocês fecharem o aplicativo e abrirem novamente, verão que ele abrirá muito mais rápido quase como se já estivesse aberto, desde que seu hardware não seja uma carroça. Isso acontece em função do Windows preservar os recuros em memória para uso posterior. O mesmo acontece com as conexões a banco de dados.
Quando comecei a programar, este foi um assunto que pesquisei muito e segundo especialistas em banco de dados (norte americanos), um conceito básico no uso compartilhado de banco de dados em redes (relacionais) é sem dúvida alguma abrir, usar e fechar o quando antes a conexão. Não só para liberar os recuros, mas como segurança do banco, mesmo que seja um SGDB.
Depois que li sobre isso e mudei, não abro mão desta forma de programação.
Não entrando no mérito da questão, pois não sou especialista, vejo frequentemente gente reclamando de problemas com os bancos de dados em muitos lugares, e isso envolve SQL Server, Oracle etc... Tive um cliente que usava meu sistema com Access (200 funcionários) e nuca teve problemas, já o outro ERP em SQL Server corrompia 2 vezes por semana no mÃnimo e vivia reclamando. O pessoal devia ter feito uma programação que Gambiarra seria luxo.
Na maioria das vezes podem ter certeza que é culpa de má programação e também conexões abertas.
Meu sistema já foi colocado a prova várias vezes por empresas de porte. A última com um cliente que trabalho a um anos, 1.500 funcionários, com cerca de 800 acessando constantemente o sistema. Então vamos lá. O programa é em VB6, MSAccess, ADO 2.6. A conexão e aberta e fechada sempre o mais rápido possÃvel.
Baseado num cenário destes, 100% iriam dizer que isso ficaria uma carroça. Não há nenhuma reclamação de lentidão, inclusive há várias unidades remotas acessando o mesmo servidor via Teminal Server. Tudo funciona perfeitamente.
Então se a codificação for bem feita, o cabeamento da empresa e o hardware for bem dimensionado, não há problemas de lentidão. A abertura e fechamento é rápido o que demora são as consultas, estas devem ser otimizadas. Agora realmente se o servidor for inadequado, memória limitada, cabeamento precário, configuração do SO equivocada e programação deficiente, será um problema atrás do outro.
Nota: Já tive problemas de lentidão que não tinham qualquer relação com meu aplicativo, os vilões eram outros e depois de detectados, tudo funcionou perfeitamente ex. de problemas:
Firewall ZoneAlarme
Antivirus Norton e MCaffee
Servidores mal configurados
Tópico encerrado , respostas não são mais permitidas