FORMA DE CONEXÃO COM O BANCO DE DADOS

POCE1DON 05/09/2015 23:19:03
#451079
Blz?

Sempre tive essa dúvida e nunca encontrei informações concretas sobre a diferença quanto à isso.

Realizo a conexão com meu BD com a engine
[Ô]PROVIDER=Microsoft.Jet.OLEDB.4.0; DATA SOURCE=caminho\bancodedados.mdb; JET OLEDB:DATABASE PASSWORD=senha;[Ô]
e faço isso sempre que preciso de algum acesso e não quando inicio o sistema, declaro minha conexão e defino a string.

Isso é certo ou errado?
Qual a diferença em declarar uma conexão publica ao iniciar o sistema, manter aberta para ser usada em todos
os recordset e encerrá-la apenas quando finalizar o sistema?

Em alguns casos, o programa funciona apenas local, mas em outros é necessário compartilhar o BD e o acesso
fica local e também compartilhado por estações.

Outra dúvida:
No caso do acesso compartilhado, faz alguma diferença indicar o caminho para o BD sendo [Ô]\\(nomedamaquina ou ip)\bancodedados.mdb[Ô] ou é necessário realizar o mapeamento de uma unidade de rede?

Essa dúvida é por conta de problemas que estou passando com a falta de atualizações no BD, a máquina está comunicando normalmente, seja ela uma estação ou a local, as vezes acontece alterações no BD, como a quantidade de itens de um produto, e isso não é registrado. Não há hora pra isso acontecer, tem dia que tudo funciona normalmente, mas outros não.

Será que está influenciado essa forma de indicar o caminho do BD [Ô]\
omedamaquina\bd[Ô] nas estações, e também declarando a conexão sempre que vou utilizar ao invés de quando o sistema é iniciado?

Obrigado pela atenção aí amigo!
KERPLUNK 05/09/2015 23:50:54
#451080
Vamos lá:
1 - Não existe certo ou errado nesse caso. Existe mais cômodo ou menos cômodo. Mais eficiente e menos eficiente. OleDB, que é o que você está usando é notoriamente conhecido por não ser muito eficiente quanto à conexão. O problema é esquecer de fechar essa conexão ao fechar o programa. E se o programa tiver algum erro e for encerrado prematuramente, é possível que a conexão fique aberta por um longo período de tempo.
2 - O uso de uma pasta mapeada, costuma ser mais rápido do que especificar apenas o caminho do compartilhamento. Isso porque, mesmo indicando o caminho do compartilhamento, uma espécie de mapeamento interno é feita toda a vez que tentar conectar. Então mapear a pasta é mais eficiente.

Algumas considerações:
- O uso de um bando(isso mesmo BANDO DE DADOS) access, não é nem de perto tão eficiente quanto usar um SGDB, como SQL Server ou MySQL. Por isso, considere a migração para uso de um banco de dados de verdade.
- Considere também escrever seu código de maneira que facilite uma eventual migração para .NET, porque é quase certeza que mais dia, menos dia, isso vai ser necessário.
POCE1DON 07/09/2015 01:21:15
#451098
Citação:

:
Vamos lá:
1 - Não existe certo ou errado nesse caso. Existe mais cômodo ou menos cômodo. Mais eficiente e menos eficiente. OleDB, que é o que você está usando é notoriamente conhecido por não ser muito eficiente quanto à conexão. O problema é esquecer de fechar essa conexão ao fechar o programa. E se o programa tiver algum erro e for encerrado prematuramente, é possível que a conexão fique aberta por um longo período de tempo.
2 - O uso de uma pasta mapeada, costuma ser mais rápido do que especificar apenas o caminho do compartilhamento. Isso porque, mesmo indicando o caminho do compartilhamento, uma espécie de mapeamento interno é feita toda a vez que tentar conectar. Então mapear a pasta é mais eficiente.

Algumas considerações:
- O uso de um bando(isso mesmo BANDO DE DADOS) access, não é nem de perto tão eficiente quanto usar um SGDB, como SQL Server ou MySQL. Por isso, considere a migração para uso de um banco de dados de verdade.
- Considere também escrever seu código de maneira que facilite uma eventual migração para .NET, porque é quase certeza que mais dia, menos dia, isso vai ser necessário.



Pow KERPLUNK, vc esclareceu dúvidas mas trouxe medo de [Ô]brinde[Ô], kkkkkkkk...

Se a forma de conexão que uso não é a mais eficiente, qual então seria e vc recomenda?

Sei que o Access está bem, mas beeeemmmm ultrapassado em relação às tecnologias que temos
disponíveis hj, como as que sitou, mas atualmente estou muito sem tempo pra realizar o estou e
fazer essa migração. Vejo e tenho acesso a diversos sistemas que ainda funcionam com esse BD
e sem maiores problemas, mas como disse, [Ô]o dia[Ô] pode estar próximo do problema aparecer.

Preciso mesmo partir para o dot.Net, mas o tempo não tem me permitido entrar nos estudos (isso que dá trabalhar sozinho e não em equipe), e
assim que entrar na linguagem, aí vem o BD, ou seja, quase será o recomeço de tudo.
Estou em busca de alguém aqui na cidade para fazer a parceria, essa pessoa cuidando do BD e eu com a linguagem, já que iniciar agora
tudo sozinho, como falei, irá me tomar muito tempo fazendo a migração dos projetos para as novas linguagens e tudo funcionar perfeitamente
sem problemas e o melhor, com as novas facilidades/recursos.

Mas obrigado por seus esclarecimentos KERPLUNK, vou deixar o tópico aberto para, quem sabe, mais alguém se manifestar, certo?.

Abrax!
DS2T 07/09/2015 02:06:54
#451099
Vou tentar ser sucinto.

O ideal é que faça a conexão, use-a e depois a feche. Sendo completamente sincero contigo, quando comecei a programar (a uns 10 anos atrás) eu deixava a variável de conexão no módulo como pública também. Nunca tive problema algum com isso. Mas já ouvi casos de pessoas que quando deixava o sistema ocioso, a conexão se perdia (Isso por causa do próprio SGBD) ou apresentava anomalias. Felizmente nunca passei por isso. Mas seja como for, não tem porque deixar a conexão aberta...

Sobre o caminho sem mapeamento de unidade, não faz diferença.

Sobre o seu problema, provavelmente é por causa do banco de dados Access. Eu vejo muitos programadores com ódio no coração com Access, simplesmente porque o comparam com SQL Server, MySQL, Oracle, PostGreSQL... Poxa, é completamente diferente. Uma coisa é uma coisa, outra coisa é outra coisa.

Eu gosto do Access, tem uns recursos interessantes de relatórios, o fato de você poder usar VBA lá também ajuda um bocado. Tem uns assistentes legais e uma interface amigável. Mas ele não foi feito para trabalhar em rede, nem trabalhar em alta performance com grandes quantidades de dados. Não vejo mal nenhum em usar o Access pra trabalhar
A própria Microsoft deixa claro na sua documentação que não recomenda o uso de Access em rede. Primeiro porque pode corromper, segundo, justamente por esses problemas de atualização.,,

Beleza?

Abraços.

ACCIOLLY 07/09/2015 08:59:48
#451100
Quando programava em vb6 o access pra mim era tudo! mesmo quando dava pau na rede. Hoje sou mais flexível (ou a palavra certa seria eclético). A questão é termos o bom censo e avaliarmos com antecedencia a usabilidade de nossas aplicações. A visão analítica é tão fundamental quanto o desenvolvimento de um programa.

DS2T eu também gosto do access. mas isso quando desenvolvo aplicações pra uma máquina! Quando desenvolvo aplicações de grande porte, eu prefiro um dos SGDB[ô]s citados acima. Devido a sua segurança, usabilidade e principalmente sua durabilidade. Uma vez criei um programa com BD em access e quando o BD alcançou um pouco mais de 1,5GB ele se corrompeu! e o cliente perdeu tudo! Mas agente quando é novato sempre aprende com o erros!

Quanto a forma de conexão, na minha opinião independente do banco que estiver utilizando, o ideal é abrir a conexão no momento em que for fazer uma operação (SELECT, INSERT, UPDATE, DELETE) e fechar logo em seguida. Assim o banco fica mais rápido. Imagine uma empresa com 500 funcionários operando o mesmo sistema de gerenciamento com BD MySql. Se este sistema só fecha a conexão quando é encerrado qual seria o comportamento desse banco?

1 - Ótimo
2 - Bom
3 - Regular
4 - Ruim
5 - Uma bosta!

A resposta vai ser quenem o tiririca, o dia q eu fizer um desses eu te respondo! rsrsrsrsrs

Mas na teoria, isso pode trazer problemas sérios. O banco fica muito pesado. Mas se vc fechar a conexao logo após uma operação, a resposta vai ser mais rápida. Eu uso OLEDB, mas da seguinte forma:
1º crio uma classe de conexão com a string connection de minha preferencia;
2º dentro da classe de conexão já crio um método de pesquisa que passo como parametro uma SQL, então ele abre a conexao, faz a pesquisa com esse parametro depois fecha a conexao e por fim me retorna um DataTable com esses dados.
3º Também crio na classe de conexão um método de CRUD que vai servir para as outras três operações (INSERT, UPDATE e DELETE). Nela também passo como parametro um SQL, depois vai fazer a operação desejada segundo o comando SQL e logo fecha a conexao;
4º Daí nas classes dos forms eu instancio essa classe de conexao, e é só usar os dois métodos dela.

Assim eu evito tanto o desgaste do banco, quanto da aplicação e é claro o meu! já pensou eu ter que digitar toda vez uma string de conexao toda vez que for fazer uma operação no banco? tá certo que tem Ctrl+C e Ctrl+V, mas estéticamente a codificação fica bem mais enxuta, e o resultado vai ser o mesmo!

Té mais
POCE1DON 08/09/2015 02:52:25
#451113
Citação:

:
Vou tentar ser sucinto.

O ideal é que faça a conexão, use-a e depois a feche. Sendo completamente sincero contigo, quando comecei a programar (a uns 10 anos atrás) eu deixava a variável de conexão no módulo como pública também. Nunca tive problema algum com isso. Mas já ouvi casos de pessoas que quando deixava o sistema ocioso, a conexão se perdia (Isso por causa do próprio SGBD) ou apresentava anomalias. Felizmente nunca passei por isso. Mas seja como for, não tem porque deixar a conexão aberta...

Sobre o caminho sem mapeamento de unidade, não faz diferença.

Sobre o seu problema, provavelmente é por causa do banco de dados Access. Eu vejo muitos programadores com ódio no coração com Access, simplesmente porque o comparam com SQL Server, MySQL, Oracle, PostGreSQL... Poxa, é completamente diferente. Uma coisa é uma coisa, outra coisa é outra coisa.

Eu gosto do Access, tem uns recursos interessantes de relatórios, o fato de você poder usar VBA lá também ajuda um bocado. Tem uns assistentes legais e uma interface amigável. Mas ele não foi feito para trabalhar em rede, nem trabalhar em alta performance com grandes quantidades de dados. Não vejo mal nenhum em usar o Access pra trabalhar
A própria Microsoft deixa claro na sua documentação que não recomenda o uso de Access em rede. Primeiro porque pode corromper, segundo, justamente por esses problemas de atualização.,,

Beleza?

Abraços.



Bom, não tenho dúvidas que a questão da forma da conexão que está sendo realizada em alguns de meus pequenos projetos, foram feitas erradas, fruto da minha busca de conhecimento, na época, pela internet em sites como o do macoratti.net. Lembro-me bem, isso à quase 4 anos, que em um de seus tutoriais sobre conexões com BD ele ensinava que ela deveria ser aberta ao iniciar o sistema e encerrada ao finalizar, mas sempre achei a [Ô]teoria[Ô] muito estranha, já que enquanto a máquina/estação ficava ociosa, lá estava aquela comunicação com o BD sem necessidade. Mas tudo bem, agora já era, o que vale é a experiencia própria e não toda aquela teoria.

Obrigado por suas informações amigo!

Citação:

:
Quando programava em vb6 o access pra mim era tudo! mesmo quando dava pau na rede. Hoje sou mais flexível (ou a palavra certa seria eclético). A questão é termos o bom censo e avaliarmos com antecedencia a usabilidade de nossas aplicações. A visão analítica é tão fundamental quanto o desenvolvimento de um programa.

DS2T eu também gosto do access. mas isso quando desenvolvo aplicações pra uma máquina! Quando desenvolvo aplicações de grande porte, eu prefiro um dos SGDB[ô]s citados acima. Devido a sua segurança, usabilidade e principalmente sua durabilidade. Uma vez criei um programa com BD em access e quando o BD alcançou um pouco mais de 1,5GB ele se corrompeu! e o cliente perdeu tudo! Mas agente quando é novato sempre aprende com o erros!

Quanto a forma de conexão, na minha opinião independente do banco que estiver utilizando, o ideal é abrir a conexão no momento em que for fazer uma operação (SELECT, INSERT, UPDATE, DELETE) e fechar logo em seguida. Assim o banco fica mais rápido. Imagine uma empresa com 500 funcionários operando o mesmo sistema de gerenciamento com BD MySql. Se este sistema só fecha a conexão quando é encerrado qual seria o comportamento desse banco?

1 - Ótimo
2 - Bom
3 - Regular
4 - Ruim
5 - Uma bosta!

A resposta vai ser quenem o tiririca, o dia q eu fizer um desses eu te respondo! rsrsrsrsrs

Mas na teoria, isso pode trazer problemas sérios. O banco fica muito pesado. Mas se vc fechar a conexao logo após uma operação, a resposta vai ser mais rápida. Eu uso OLEDB, mas da seguinte forma:
1º crio uma classe de conexão com a string connection de minha preferencia;
2º dentro da classe de conexão já crio um método de pesquisa que passo como parametro uma SQL, então ele abre a conexao, faz a pesquisa com esse parametro depois fecha a conexao e por fim me retorna um DataTable com esses dados.
3º Também crio na classe de conexão um método de CRUD que vai servir para as outras três operações (INSERT, UPDATE e DELETE). Nela também passo como parametro um SQL, depois vai fazer a operação desejada segundo o comando SQL e logo fecha a conexao;
4º Daí nas classes dos forms eu instancio essa classe de conexao, e é só usar os dois métodos dela.

Assim eu evito tanto o desgaste do banco, quanto da aplicação e é claro o meu! já pensou eu ter que digitar toda vez uma string de conexao toda vez que for fazer uma operação no banco? tá certo que tem Ctrl+C e Ctrl+V, mas estéticamente a codificação fica bem mais enxuta, e o resultado vai ser o mesmo!

Té mais



é ACCIOLLY, não tem jeito, vou ter que migrar alguns de meus projeito para outro BD.

Estou revisando as query de um dos sistemas porque preciso melhorar a performace. A empresa do cliente está crescendo, estão me cobrando mais recursos dentro do sistema, vão aumentar as estações, haverá um servidor dedicado ao invés de uma máquina comum apenas compartilhando, por isso o motivo desse tópico para troca de informações sobre as experiencias que os colegas já passaram.

Até então o BD não está gigante como do seu cliente, que teve a [Ô]sorte[Ô] de corromper, até chegar à isso ainda vai levar um bom tempo, mas....

Informação ou aprender, nunca é tarde ou pouco, além de todos os dias algo na vida nos ensina uma novidade, já que devemos viver hoje, amanhã será uma novidade e ontem nunca mais veremos. Então, talvez vc tenha dos seus antigos materiais, um módulo ou um simples projeto que já esteja aplicado essa sua forma de desenvolvimento da comunicação e consulta e possa me enviar para que sirva de um novo conhecimento à mim.

Você teria e seria possível me enviar?

Desde já e Vlw pela participação aí amigo!
ACCIOLLY 08/09/2015 14:42:07
#451132
Sinceramente a forma de compartilhamento do seu banco pouco importa. Eu particularmente colocaria um ip fixo em cada máquina, o que facilitaria seu mapeamento, e chamava o caminho do banco pelo IP na rede. O que realmente importa é que, independente do banco [Ô]Não Pode[Ô] haver várias conexões simultaneas.
Desta forma:
1 - você pode ter uma rede com 200 máquinas e um banco em access que não te dá problema algum quando vc conecta a ele sempre que for fazer operações.
2 - você pode ter uma rede com 2 máquinas e um banco access que te dão dor de cabeça o tempo todo quando ambas as máquinas estão com a conexao aberta desde sua inicialização.
Portanto seja a linguagem com que trabalha, o banco com que trabalha, a regra vale pra todos e todas!

Infelizmente não tenho mais projetos antigos em vb6 pois fiz um limpa na minha máquina e na minha mente! rsrsrsrs. Por isso que gosto do Ken Tompson [Ô]Um dos meus dias mais produtivos foi quando eu joguei fora 1000 linhas de código[Ô] Na verdade foram bem mais! rsrsrsr. Cara quando agente evolui, conhece linguagens mais novas, e não sobra mais espaço na máquina dagente, agente tem que se livrar do lixo! rsrsrs Mas se você quiser te passo umas formas muito boas tanto pra VB.Net quanto pra C#, e tanto pro access quanto pro MySql.

Então a forma como vc faz a conexão ao banco não está errada. Pois pelo que entendi você:

1 - Utiliza o IP do servidor ao invés do nome na rede => correto
2 - Só conecta ao banco quando faz alguma operação (INSERT, UPDATE, DELETE e SELECT) => Corrento
3 - Logo após fazer qualquer operação no banco a conexão é fechada =>100% Corrento. (Sem dúvida isso é muito importante e crucial em muitos casos que vejo)

Se você segue essas três regras básicas dificilmente vai encontrar problemas, a menos que no exato momento (questão de décimos de segundos dependendo do tamanho do banco e da velocidade da rede) haja conexões multiplas a este banco.
Agora se seu sistema conecta ao banco no momento em que inicia e fecha a conexao quando é encerrado, é procurar pra cabeça! vai por mim! rsrsrsr

Té mais.
Faça seu login para responder