Olá,

 

Tudo o que você pergunta é relativo. Na teoria, o Access suporta 255 conexões simultâneas e a capacidade de armazenamento pode chegar a alguns gigabytes. Bom isso é teoria, na prática o Access não reage muito bem a muitas conexões simultâneas nem a arquivos de banco de dados muito grandes, pois além de perigoso, é muito lento (entenda perigoso como a grande possibilidade de corrupção do arquivo e consequente perda de dados).

Pelo que você descreve, a empresa possui uma estrutura bem maior, nesse caso você deve observar a estrutura da rede. Ela é bem estável, ou sofre muita influência de queda de energia ou perda de conexões frequentemente? Quantas máquinas deverão accessar o banco ao mesmo tempo, e qual a quantidade de dados que o banco deverá comportar?

Lembre-se (e lembre os seus clientes também): o Access não é um banco cliente/servidor, portanto não espera grandes recursos de recuperação de desastres, backup ou segurança de dados. Ele é um banco de dados desktop para bancos com poucos acesso simultêneos e arquivos não muito grandes. Se o número de acessos simultêneos ultrapassar 50 máquinas e o banco tiver que armazenar muita informação, considere o uso de um SQL Server ou Oracle (MySQL também pode ajudar, mas eu nunca o utilizei; nem sei como é a cara dele...).

Com relação a codificar dentro do Access, esqueça. É um tremendo problema que você irá enfrentar. Na maioria dos casos, você tem que desviar das regras de estruturação de bancos de dados para fazer o programa funcionar normalmente. Além disso, tirando os relatórios, a execução é mais lenta que através de linguagens como VB. Outra: o código dentro do VB está protegido contra "abelhudos" que possam cismar em mexer no programa e estragar dias de trabalho em poucos segundos. Outra boa recordação: Access não é linguagem de programação. Embora ele inclua o VBA, um subset de instruções baseadas em VB, ele não é um comopilador e não possui recursos de otimização de código como o Vb ou outra linguagem (Delphi, por exemplo). Já vi muitos programas muito interessantes feitos dentro do Access, mas o desempenho em grandes redes e com bases muito grandes era muito precário e o banco se corrompia com frequência.

Eu acho mais interessante desenvolver o banco em Access, planejando uma migração para o SQL Server (isso inclui a não utilização de recursos que o SQL Server não possui, como Consultas de Referência Cruzada) e desenvolver o programa dentro do VB ( o fato do programa poder "dar pau" no Vb não exclui a mesma possibilidade dentro do Access, dependendo do tipo de erro que ocorra. Na maioria dos casos não faz diferença, pois o erro deverá ser de lógica do programa ou de deficiências na rede ou nos computadores). uma dica: evite a todo custo os controles acoplados a dados, como o ADODC, DataControl e outros. Você até pode utilizar uma DataGrid ADO, mas use como fonte de dados um objeto ADODB.Recordset definido via código. Isso garante duas coisas: flexibilidade na validação mais complexa dos dados e desempenho, além de estabilidade.

 

um abraço,

Sandro.