UPDATE X CONSULTA ACCESS
Amigos,
Estou fazendo um controle de estoque vb6 e estou inclinado a fazer as consultas atualização no access e executa las atráves do vb, vcs que são mmmmmmuuuuuuuuuiiiiiiiittttttoooooo mais conhecedores de problemas com teste no programa, por favor me informem:
isso da problema sendo usado em mais de uma estação?
é viavel fazer desta forma?
desde já lhes agradeço.
Estou fazendo um controle de estoque vb6 e estou inclinado a fazer as consultas atualização no access e executa las atráves do vb, vcs que são mmmmmmuuuuuuuuuiiiiiiiittttttoooooo mais conhecedores de problemas com teste no programa, por favor me informem:
isso da problema sendo usado em mais de uma estação?
é viavel fazer desta forma?
desde já lhes agradeço.
muiiito conhecedores ?
Exagero.
Aplicações Multi-User e/ou Client-Server e/ou as que tendem armazenar mais de 2 GB (Limite de arquivos .mdb) devem optar por SGBD tais quais MSSQL Server Express o mais facilmente migravel, Firebird, Oracle Express etc
Todas soluções Free que contem segurança e desempenho simplesmente acopladas pelo seu uso.
Por favor leia os motivos no topico abaixo para NÃO usar access se deseja implementar um sistema com real qualidade de segurança e desempenho neste tipo de ambiente.
http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=215641
Respondendo sua pergunta, para não continuarem me acusando de desvirtuar tópicos.
Eu optei certa vez por este tipo de programação, mas ela não me economizou código e nem aumentou desempenho uma vez que o cursor das consultas sempre são executados na mákina client conforme explicado no link.
A única diferença foi complicar de fato a programação e nem para uma eventual migração serviu direito.
Funciona, não aumenta desempenho, dificulta o código, não deixa o sistema mais seguro além de ter um limite de 2 GB.
Usando MSSQL Express a única limitação que permanece é a de 2GB e utilizar apenas 1 processador (existem caso de servidores com 2 processadores parrudos) .. só que se chegar a isto para migrar para um MSSQL Server 2005 (Pago) é só instalar por cima do Express (Free) basicamente.
Tae meus argumentos, não disse que não funciona sua tecnica ... disse que testei e tive o resultado apresentados acima (Inclusive testando tabelas com muitos itens e em rede)
Se eu fosse vc economizaria estas semanas de aprendizado e partiria para algo mais SOLIDO ... esta é a palavra.
Exagero.
Aplicações Multi-User e/ou Client-Server e/ou as que tendem armazenar mais de 2 GB (Limite de arquivos .mdb) devem optar por SGBD tais quais MSSQL Server Express o mais facilmente migravel, Firebird, Oracle Express etc
Todas soluções Free que contem segurança e desempenho simplesmente acopladas pelo seu uso.
Por favor leia os motivos no topico abaixo para NÃO usar access se deseja implementar um sistema com real qualidade de segurança e desempenho neste tipo de ambiente.
http://www.vbmania.com.br/vbmania/vbmforum.php?varMethod=Abrir&varID=215641
Respondendo sua pergunta, para não continuarem me acusando de desvirtuar tópicos.
Eu optei certa vez por este tipo de programação, mas ela não me economizou código e nem aumentou desempenho uma vez que o cursor das consultas sempre são executados na mákina client conforme explicado no link.
A única diferença foi complicar de fato a programação e nem para uma eventual migração serviu direito.
Funciona, não aumenta desempenho, dificulta o código, não deixa o sistema mais seguro além de ter um limite de 2 GB.
Usando MSSQL Express a única limitação que permanece é a de 2GB e utilizar apenas 1 processador (existem caso de servidores com 2 processadores parrudos) .. só que se chegar a isto para migrar para um MSSQL Server 2005 (Pago) é só instalar por cima do Express (Free) basicamente.
Tae meus argumentos, não disse que não funciona sua tecnica ... disse que testei e tive o resultado apresentados acima (Inclusive testando tabelas com muitos itens e em rede)
Se eu fosse vc economizaria estas semanas de aprendizado e partiria para algo mais SOLIDO ... esta é a palavra.
Concordo com nosso amigo EMERSON_TADEU.
BOM minha opinião é a seguinte....
eu prefiro nao usar consultas sqls pq, qndo desenvolvo um sistema ele teoricamente tem q ser mono ou multiusuario...
qndo é mono ja se acredita q o sistema teoricamente tende a ter um menor fluxo de informação entao pra q instalar um SGBD e nao optar por um simples arquivinho mdb ....
agora pq eu nao gosto de usar as facilidades de uma sql interna (claro q dependendo do caso eu uso e ate stores ...)
pelo seguinte digamos q eu use uma consulta interna no accesss e depois no vb eu faça algo do tipo
select * from(select * ....) ou seja buscar informações de uma sql, isso no access funfa, no fire nao, no mysql dependendo da versao tb nao
se eu tiver apenas uma sql com filtros interna no banco e apenas trazer ela pelo vb ou seja select * from consultasqlinterna no fire no access funfa no mysql 4 nao so no 5 e as vezes dependendo do provedor do cliente so tera o mysql 4
eu acho q se vc perder um tempinho a mais e nao é nada absurdo vc ganha escabilidade, portabilidade e nao fica preso sem contar como o proprio emerson falou vc tem um aprendizado e parte pra algo mais solido ....
eu no seu lugar demoraria mais um pouco ou entao faria as consultas internas mesmo e pra poder cumprir prazos e depois mexeria denovo de modo a ajustar .....
mudando de assunto pode-ser q eu esteja errado ate gostaria de saber do emerson q mexe mais com sql server mas as versoes free do sql server e do oracle nao tem limite tb de tamanho de 2G?
mas por fim uso as palavras
eu prefiro nao usar consultas sqls pq, qndo desenvolvo um sistema ele teoricamente tem q ser mono ou multiusuario...
qndo é mono ja se acredita q o sistema teoricamente tende a ter um menor fluxo de informação entao pra q instalar um SGBD e nao optar por um simples arquivinho mdb ....
agora pq eu nao gosto de usar as facilidades de uma sql interna (claro q dependendo do caso eu uso e ate stores ...)
pelo seguinte digamos q eu use uma consulta interna no accesss e depois no vb eu faça algo do tipo
select * from(select * ....) ou seja buscar informações de uma sql, isso no access funfa, no fire nao, no mysql dependendo da versao tb nao
se eu tiver apenas uma sql com filtros interna no banco e apenas trazer ela pelo vb ou seja select * from consultasqlinterna no fire no access funfa no mysql 4 nao so no 5 e as vezes dependendo do provedor do cliente so tera o mysql 4
eu acho q se vc perder um tempinho a mais e nao é nada absurdo vc ganha escabilidade, portabilidade e nao fica preso sem contar como o proprio emerson falou vc tem um aprendizado e parte pra algo mais solido ....
eu no seu lugar demoraria mais um pouco ou entao faria as consultas internas mesmo e pra poder cumprir prazos e depois mexeria denovo de modo a ajustar .....
mudando de assunto pode-ser q eu esteja errado ate gostaria de saber do emerson q mexe mais com sql server mas as versoes free do sql server e do oracle nao tem limite tb de tamanho de 2G?
mas por fim uso as palavras
Citação:FRAU escreveu:
Concordo com nosso amigo EMERSON_TADEU.
Respondendo ao nosso amigo WEBER (Grande amigo):
SQL Server 2005 Express (Free) tem como limitações principais o Limite de 2 GB além de não utilizar um eventual 2º Processador o que impede definitivamente de ser utilizado para grandes aplicações, mas isto não atrapalha novos desenvolvedores de adquirir as técnicas necessárias para o desenvolvimento de pequenos aplicativos pois permite total programabilidade.
SQL Server 2005 Express (Free) tem como limitações principais o Limite de 2 GB além de não utilizar um eventual 2º Processador o que impede definitivamente de ser utilizado para grandes aplicações, mas isto não atrapalha novos desenvolvedores de adquirir as técnicas necessárias para o desenvolvimento de pequenos aplicativos pois permite total programabilidade.
Usar um Command para uma SP sem parâmetros é pêrda de tempo (muito código para pouco resultado). Melhor abrir uma View direto com um Recordset.
Usar um Command para uma SP com parâmetros requer um pouco mais de código e só apresenta vantagens realmente quando você processa lotes de atualizações em várias tabelas, e deve usar transações para garantir que, em caso de erros, possa voltar ao ponto anterior ao inÃÂÂcio do processo (rollback).
Com a ADO, você pode se beneficiar dos Command para, por exemplo, chamar Functions armazenadas, com parâmetros de entrada e / ou saÃÂÂda. Desse modo, por exemplo, você pode criar uma function que grave um novo registro, informe o valor do autonumerador / identity desse novo registro, replique a operação em outros bancos / catálogos e ainda dispare mensagens de erro customizadas.
A outra forma, é a de processar lotes de dados, como citei. Por exemplo, onde não há a necessidade de replicação (de informação atualizada constantemente), uma filial pode enviar todo o processamento do dia para a matriz, que irá então tratar os lotes de cada filial na base central. é uma situação que demanda um bom controle de erros.
Nessas situações, creio, até vale á pena. Fora isso, faz-se uso dos Command com SPs, Functions e Views também, claro, mas acho que é mais por gosto mesmo.
E no caso do MS-Access, onde o desempenho chega á ser pior, nem se fala. Algumas SPs que você faça podem literalmente "congelar" a aplicação por segundos, quando um comando direto não faz isso.
Mas veja muito bem:
A situação muda radicalmemte na plataforma DotNET, onde usar um Command é realmente tranqûilo, rápido e eficiente, além do quê, você pode dispensar totalmente os "AppendChunk" e "GetChunk" da vida e partir para o trabalho sério.
Linguagens como o Java da Sun, o PHP, o Delphi e outras já se utilizam da plataforma DotNet, o que demonstra claramente que há uma tendência ao uso da ADO.NET, mesmo que não se use o Visual Studio.
Assim, não é porquê no VB5 / VB6 nem sempre é útil que não valha á pena conhecer bem o conceito da ferramenta. Lembre-se de que o VB6 não está mais "no topo" nem possui mais suporte do fabricante.
Usar um Command para uma SP com parâmetros requer um pouco mais de código e só apresenta vantagens realmente quando você processa lotes de atualizações em várias tabelas, e deve usar transações para garantir que, em caso de erros, possa voltar ao ponto anterior ao inÃÂÂcio do processo (rollback).
Com a ADO, você pode se beneficiar dos Command para, por exemplo, chamar Functions armazenadas, com parâmetros de entrada e / ou saÃÂÂda. Desse modo, por exemplo, você pode criar uma function que grave um novo registro, informe o valor do autonumerador / identity desse novo registro, replique a operação em outros bancos / catálogos e ainda dispare mensagens de erro customizadas.
A outra forma, é a de processar lotes de dados, como citei. Por exemplo, onde não há a necessidade de replicação (de informação atualizada constantemente), uma filial pode enviar todo o processamento do dia para a matriz, que irá então tratar os lotes de cada filial na base central. é uma situação que demanda um bom controle de erros.
Nessas situações, creio, até vale á pena. Fora isso, faz-se uso dos Command com SPs, Functions e Views também, claro, mas acho que é mais por gosto mesmo.
E no caso do MS-Access, onde o desempenho chega á ser pior, nem se fala. Algumas SPs que você faça podem literalmente "congelar" a aplicação por segundos, quando um comando direto não faz isso.
Mas veja muito bem:
A situação muda radicalmemte na plataforma DotNET, onde usar um Command é realmente tranqûilo, rápido e eficiente, além do quê, você pode dispensar totalmente os "AppendChunk" e "GetChunk" da vida e partir para o trabalho sério.
Linguagens como o Java da Sun, o PHP, o Delphi e outras já se utilizam da plataforma DotNet, o que demonstra claramente que há uma tendência ao uso da ADO.NET, mesmo que não se use o Visual Studio.
Assim, não é porquê no VB5 / VB6 nem sempre é útil que não valha á pena conhecer bem o conceito da ferramenta. Lembre-se de que o VB6 não está mais "no topo" nem possui mais suporte do fabricante.
amigos,
agradeço pelas respostas, vou estudar mysql.
agradeço pelas respostas, vou estudar mysql.
Tópico encerrado , respostas não são mais permitidas