QUANTAS CONEXOES SIMULTANEAS DO ACCESS
Galera, tenho um sistema que desenvolvi no Access2000 e funciona em uma empresa há mais de três anos sem nenhum problema. O sistema funciona em rede e é acessado por aproximadamente quinze máquinas simultâneamente e nunca tive qualquer problema. Agora a empresa implantou outros departamentos e me solicitou a implentação de novas funcionalidades e disponbilizar o sistema para o acesso para 30 máquinas. Estou meio apreensivo, pois apesar da Microssoft afirmar que o acess suporta até 255 conexões, sabemos que isto não é uma realidade. Gostaria de saber se alguém possui algum sistema em access2000 funcionando e com quantas conexões disponilizadas para acesso.
Grato.
Grato.
Creio que você não encontrará nenhum problema ao disponibilizar acesso á mais quinze estações. E mesmo que fossem mais trinta estações. O MS-Access suporta de fato até 255 conexões simultâneas, assim como até 2 giga bytes em tamanho total de arquivo.
Veja que estou falando especificamente sobre capacidades e de limites.
Apesar de esta capacidade ser efetiva, ou seja, que foi comprovada na prática, ocorrem decréscimos de performance decorrentes de duas situações:
1.- A cada 50 conexões simultâneas (provavelmente porquê o arquivo temporário seja atualizado com maior freqüência);
2.- A cada 250 Mbytes (provavelmente em decorrência do pacote de rede, e não por conta do mecanismo de dados);
3.- Ao utilizar o arquivo de sistema de grupo de acesso em redes P2P ou sob gerenciadores de rede não-Windows (neste caso, não consegui identificar nenhum motivo aparente, mas a dedução mais lógica é que o acesso ao arquivo de sistema [Ô]force[Ô] algum delay extra na rede).
Aproveitando:
Como o mecanismo permite lidar com bases vinculadas, é possÃvel trabalhar com vários arquivos MS-Access simultâneos, até o limite de 32768 entidades (tabelas, consultas etc), [Ô]quebrando[Ô] fácil o limite de 2Gbytes por arquivo, mantida a ressalva da performance, além de algumas outras, como por exemplo, evitar consultas com mais de 170 cláusulas WHERE, [Ô]ponderar[Ô] bastante bem a adoção e o uso de Ãndices, [Ô]isolar[Ô] entidades de dependência forte em um mesmo arquivo fÃsico etc.
De forma geral, ao adotar o uso do MS-Acces SEM o arquivo de sistema de grupo de trabalho, o limite de conexões simultâneas não chega á afetar, pois se seus aplicativos utilizarem o [Ô]On-Demand Connection[Ô], mesmo que 500 terminais estejam [Ô]olhando[Ô] e processando os mesmos dados, dificilmente estarão conectados simultaneamente.
Um outro problema porém, que nada tem á ver com a quantidade de conexões simultâneas, é que bases de dados MS-Access, quando conectados aos clients, costumam sofrer corrupção, notadamente quando o buffer de rede sofre algum [Ô]delay[Ô], pêrda de sinal ou remapeamento.
Desta forma, o ideal, ao adotar o MS-Access como mecanismo de dados, uma vez confirmando-se que a qualidade do hardware de rede seja confiável e principalmente estável, é [Ô]fazer de conta[Ô] que há duas [Ô]regras absolutas[Ô], á saber:
1.- Adotar o modelo [Ô]On-Demand Connection[Ô] ao invés do tradicional [Ô]Allways Connected[Ô], minimizando riscos de corrupção. O decréscimo de performance é pequeno ao conectar/desconectar quando necessário, justificando essa adoção;
2.- Ao término do uso (quando absolutamente todas as conexões se encerram), efetuar os procedimentos de backup e de compressão de dados (compressão via DAO / ADO / JET e não aquela feita por compactadores como o Winzip / WinRAR / PKZip). Invariavelmente a adoção dessa rotina diária costuma poupar muitos problemas.
Veja que estou falando especificamente sobre capacidades e de limites.
Apesar de esta capacidade ser efetiva, ou seja, que foi comprovada na prática, ocorrem decréscimos de performance decorrentes de duas situações:
1.- A cada 50 conexões simultâneas (provavelmente porquê o arquivo temporário seja atualizado com maior freqüência);
2.- A cada 250 Mbytes (provavelmente em decorrência do pacote de rede, e não por conta do mecanismo de dados);
3.- Ao utilizar o arquivo de sistema de grupo de acesso em redes P2P ou sob gerenciadores de rede não-Windows (neste caso, não consegui identificar nenhum motivo aparente, mas a dedução mais lógica é que o acesso ao arquivo de sistema [Ô]force[Ô] algum delay extra na rede).
Aproveitando:
Como o mecanismo permite lidar com bases vinculadas, é possÃvel trabalhar com vários arquivos MS-Access simultâneos, até o limite de 32768 entidades (tabelas, consultas etc), [Ô]quebrando[Ô] fácil o limite de 2Gbytes por arquivo, mantida a ressalva da performance, além de algumas outras, como por exemplo, evitar consultas com mais de 170 cláusulas WHERE, [Ô]ponderar[Ô] bastante bem a adoção e o uso de Ãndices, [Ô]isolar[Ô] entidades de dependência forte em um mesmo arquivo fÃsico etc.
De forma geral, ao adotar o uso do MS-Acces SEM o arquivo de sistema de grupo de trabalho, o limite de conexões simultâneas não chega á afetar, pois se seus aplicativos utilizarem o [Ô]On-Demand Connection[Ô], mesmo que 500 terminais estejam [Ô]olhando[Ô] e processando os mesmos dados, dificilmente estarão conectados simultaneamente.
Um outro problema porém, que nada tem á ver com a quantidade de conexões simultâneas, é que bases de dados MS-Access, quando conectados aos clients, costumam sofrer corrupção, notadamente quando o buffer de rede sofre algum [Ô]delay[Ô], pêrda de sinal ou remapeamento.
Desta forma, o ideal, ao adotar o MS-Access como mecanismo de dados, uma vez confirmando-se que a qualidade do hardware de rede seja confiável e principalmente estável, é [Ô]fazer de conta[Ô] que há duas [Ô]regras absolutas[Ô], á saber:
1.- Adotar o modelo [Ô]On-Demand Connection[Ô] ao invés do tradicional [Ô]Allways Connected[Ô], minimizando riscos de corrupção. O decréscimo de performance é pequeno ao conectar/desconectar quando necessário, justificando essa adoção;
2.- Ao término do uso (quando absolutamente todas as conexões se encerram), efetuar os procedimentos de backup e de compressão de dados (compressão via DAO / ADO / JET e não aquela feita por compactadores como o Winzip / WinRAR / PKZip). Invariavelmente a adoção dessa rotina diária costuma poupar muitos problemas.
Caro Professor,
Em primeiro lugar quero agradecer pela atenção. Fiquei contente ao ler sua resposta, pois já estou cansado de ver pessoas [Ô]metendo o pau[Ô] no access, dizendo que só serve para programinhas sem valor. E isto não é verdade. Já programo em access há bastante tempo. Gosto dele pela facilidade em seu manuseio.
Agora fiquei em dúvida em dois itens que você falou: [Ô]On-Demand Connection[Ô] e [Ô]Allways Conneted[Ô]. Qual o significado e como adotar.
Só para esclarecer, eu dividi o sistema em duas partes: o back-end e o front-end. Portanto as tabelas ficam vinculadas permanecendo no servidor. Já o front-end (com os formulários, relatórios e módulos) ficam nas estações.
Fiz uma rotina de back-up na qual quando o sistema é encerrado nas estações a base de dados seja copiado para um local previamente especificado. Só que no momento em que o back-up for realizado alguma estação estiver acessando a base de dados dá erro pois um arquivo ldb fica aberto, ainda não consegui contornar este erro.
Grato e fique com Deus.
Em primeiro lugar quero agradecer pela atenção. Fiquei contente ao ler sua resposta, pois já estou cansado de ver pessoas [Ô]metendo o pau[Ô] no access, dizendo que só serve para programinhas sem valor. E isto não é verdade. Já programo em access há bastante tempo. Gosto dele pela facilidade em seu manuseio.
Agora fiquei em dúvida em dois itens que você falou: [Ô]On-Demand Connection[Ô] e [Ô]Allways Conneted[Ô]. Qual o significado e como adotar.
Só para esclarecer, eu dividi o sistema em duas partes: o back-end e o front-end. Portanto as tabelas ficam vinculadas permanecendo no servidor. Já o front-end (com os formulários, relatórios e módulos) ficam nas estações.
Fiz uma rotina de back-up na qual quando o sistema é encerrado nas estações a base de dados seja copiado para um local previamente especificado. Só que no momento em que o back-up for realizado alguma estação estiver acessando a base de dados dá erro pois um arquivo ldb fica aberto, ainda não consegui contornar este erro.
Grato e fique com Deus.
On-Demand Connection = Abrir a conexão com o banco de dados, realizar as tarefas, e em seguida desconectar do banco.
Allways Connected = Como o próprio nome diz, é está sempre conectado, ou seja, manter a conexão ao banco aberta durante todo tempo em que a aplicação estiver carregada na memória.
Allways Connected = Como o próprio nome diz, é está sempre conectado, ou seja, manter a conexão ao banco aberta durante todo tempo em que a aplicação estiver carregada na memória.
Citação::
On-Demand Connection = Abrir a conexão com o banco de dados, realizar as tarefas, e em seguida desconectar do banco.
Allways Connected = Como o próprio nome diz, é está sempre conectado, ou seja, manter a conexão ao banco aberta durante todo tempo em que a aplicação estiver carregada na memória.
seria sempre interessante termos este tipo de legenda, pois programadores mais inexperientes podem usar o tópico como fonte de pesquisa e não entenderem termos como estes.
Quanto ao access, não que ele seja ruim mas sim por ser limitado em certas questões, por exemplo se de repente a empresa montar uma filial em outro local, e quiser o mesmo sistema nesta filial, você pode até conseguir colocar o access para funcionar na web (o que é fo...), mas ele não terá desempenho que um programa mais robusto tem, já vi colegas com sistema em access com 95 conexões simultâneas, porém será que ele tem o mesmo desempenho, como dito abrir e fechar a conexão é mais seguro, mas infelizmente isso não impede que o banco se corrompa (no caso do access isso não é incomum), e tudo isso dependerá da estrutura do seu programa, ela vai ser o pivô do bom desempenho e qualidade do mesmo.
Perfeita a explicação do professor. Até aprendi termos mais [Ô]elegantes[Ô] e corretos aos usuáis que já pratico. Muito bom, parabéns.
Só contribuindo com minha experiência, pratico tudo o explicado pelo professor, porém sempre que cito o uso do MS Access, estou me referindo ao MDB e não ao front end do MS Access (editor). Sendo assim uso apenas as tabelas desse [Ô]banco[Ô] e todo o restante é fetio em VB, ficando todas as ações SQL via ADO e JET 4.0.
Nota: Já disse isso aqui a algum tempo, uso a versão MDB do Acess 97 e não migrei para novas versões pelas seguintes razões:
- Todas as melhorias feitas no access apartir do 2000 são referentes as consultas, formulários, macros e relatórios do front end do Access, como não uso isso não preciso migrar o MDB.
- a migração para versões mais novas, cria uma nova estrutura de tabelas com vÃnculos inúteis à s aplicações com acesso via VB, só contribuindo para aumento desnecessário do MDB com o tempo, sem nenhuma utilizade. Com testes que fiz, a pura migração de versão fez o banco crecer certa de 30%, já o uso permantes gera campos com dados nulos desnecessários, então a melhor alternativa para quem precisa só da estrutura de tabelas do access com front end de outras lingugens, é usar o MDB da versão 97, Assim o limite de 2 Gigas é melhor utilizado, apesar de particularmente achar essa tamanho meio difÃcil de ser atingido sem problemas, (apenas impressão pessoal).
Meu sistema de gestão já foi acessado por 100 usuários simultaneamente, inclusive com uso de Terminal Server para acessos remotos de outras unidades, em véspera de auditorias. Nunca tive problemas [Ô]Graçpas a Deus[Ô]. Agora se seu sistema é grande, possui dados muito importantes, e exclusões frequentes, recomendaria usar um banco de verdade, mas com todas as rotinas de proteção da mesma forma, pois nenhum é infalÃvel.
Rotinas de Segurança e sempre recomendadas
- backups diários
- reparar e compactar
Só contribuindo com minha experiência, pratico tudo o explicado pelo professor, porém sempre que cito o uso do MS Access, estou me referindo ao MDB e não ao front end do MS Access (editor). Sendo assim uso apenas as tabelas desse [Ô]banco[Ô] e todo o restante é fetio em VB, ficando todas as ações SQL via ADO e JET 4.0.
Nota: Já disse isso aqui a algum tempo, uso a versão MDB do Acess 97 e não migrei para novas versões pelas seguintes razões:
- Todas as melhorias feitas no access apartir do 2000 são referentes as consultas, formulários, macros e relatórios do front end do Access, como não uso isso não preciso migrar o MDB.
- a migração para versões mais novas, cria uma nova estrutura de tabelas com vÃnculos inúteis à s aplicações com acesso via VB, só contribuindo para aumento desnecessário do MDB com o tempo, sem nenhuma utilizade. Com testes que fiz, a pura migração de versão fez o banco crecer certa de 30%, já o uso permantes gera campos com dados nulos desnecessários, então a melhor alternativa para quem precisa só da estrutura de tabelas do access com front end de outras lingugens, é usar o MDB da versão 97, Assim o limite de 2 Gigas é melhor utilizado, apesar de particularmente achar essa tamanho meio difÃcil de ser atingido sem problemas, (apenas impressão pessoal).
Meu sistema de gestão já foi acessado por 100 usuários simultaneamente, inclusive com uso de Terminal Server para acessos remotos de outras unidades, em véspera de auditorias. Nunca tive problemas [Ô]Graçpas a Deus[Ô]. Agora se seu sistema é grande, possui dados muito importantes, e exclusões frequentes, recomendaria usar um banco de verdade, mas com todas as rotinas de proteção da mesma forma, pois nenhum é infalÃvel.
Rotinas de Segurança e sempre recomendadas
- backups diários
- reparar e compactar
Tópico encerrado , respostas não são mais permitidas