MS Access Is (JET) adequado para acesso multiusuário?

Question

Eu tenho um produto projetado para ser um produto desktop usando arquivo MS Access como um DB.

Agora, alguns usuários precisa instalá-lo em poucos PCs (digamos 2 ou 3) e compartilhar o banco de dados.

Eu pensei que colocar o arquivo de MS Access em uma pasta compartilhada e acessá-lo a partir do PC, mas ... o motor a jato é projetado para acesso de vários usuários?

Todas as dicas ou coisas para estar ciente de fazer isso?

EDIT: O aplicativo é um .net, usando o banco de dados como armazenamento (não utilizar o banco de dados como frontend)

Answer 1

Há tanta desinformação nas respostas neste segmento que não sei por onde começar. Eu passei apenas 4 pontos na votação reputação para baixo as respostas com enganosa e informação errada neles.

1. o motor de banco de dados Jet (que é tudo o que está envolvido aqui, como o OP clarificado com uma edição) é, por padrão multi-usuário -. Foi construído a partir do zero para ser assim

2. partilhar um armazenamento de dados Jet é muito confiável quando a rede não é inferior. Isso significa não uma WAN e não sem fio, porque a largura de banda tem que ser suficiente para Jet para manter o arquivo LDB (para travamento multi-usuário), o que significa um ping por exemplo do seu PC local do motor de banco de dados Jet uma vez por segundo (com as configurações padrão), e porque Jet não pode recuperar de uma conexão (que é bastante comum em um ambiente sem fio) caiu.

3. a situação em que o Access cai é quando um front-end aplicativo Access MDB é compartilhada (que não é o caso para este cartaz). A razão não é porque você está compartilhando coisas que não podem ser confiavelmente compartilhados e não têm nenhuma razão para ser compartilhado. Devido à forma como objetos de acesso são armazenadas em um arquivo MDB (todo o projeto do Access é armazenado em um único campo BLOB em um registro em uma das tabelas do sistema), é muito propenso à corrupção se vários usuários abri-lo. Em minha opinião, a partilha de um front-end de acesso (ou um MDB unsplit com as tabelas e formulários / relatórios / etc. Tudo em um MDB) é a fonte para 99,99% de corrupções de arquivos Acesso / Jet.

A minha resposta básica à pergunta do OP é que, sim, Jet seria um grande armazenamento de dados para um aplicativo desse tamanho. No entanto, se houver qualquer possibilidade de todo para a população de usuários para crescer acima de 25, então talvez seja melhor começar do zero com um motor de banco de dados que é mais robusta em populações de usuários mais elevados.

Answer 2

É perfeitamente possível fazer isso; mas você deve dividir o banco de dados em um front-end (com formulários, consultas, código) e uma extremidade traseira (somente dados). Cada usuário tem que ter o front-end em seu próprio computador, ligando para o back-end compartilhado.

Será lento como Jet gera uma tonelada de tráfego de rede. A Microsoft também está depreciativo gradualmente Access como uma ferramenta de desenvolvimento. Access 2007, por exemplo, tem um modelo de segurança muito menos sofisticados do que Access 2003.

Como um longo desenvolvedor Tempo de acesso Estou gradualmente se afastando do Access.

Answer 3

Não faça isso ... as reivindicações de banco de dados Jet para ser capaz de suportar múltiplos usuários, mas é incrivelmente fácil de usar o Assistente de conversão para converter seu arquivo do Access para um banco de dados SQL Express. Esse arquivo de banco de dados pode facilmente tornar-se bloqueado por um usuário ou administrador, e todos os seus usuários não seria capaz de usar o banco de dados.

... e SQL Express é livre . Seu caminho de atualização de lá para uma instância completa do SQL Server ou algum outro banco de dados comercial é simples.

Answer 4

Com 2 ou 3 usuários em uma rede local de confiança que deve ser fina, contanto que você faça backup da rede dirigir-se muitas vezes.

Evite quaisquer campos de bits / bool em suas tabelas -. Jet tem alguns problemas de corrupção desagradáveis ??com acesso múltiplo para eles

Também tenha em mente que todos bloqueio no Access é otimista:. Você vai ficar sujo lê ocasionalmente

MS Access é projetado para cenários de escritórios pequenos como este:. Uso de escritório luz não-crítico que você pode configurar com o mínimo de programação

Espere o arquivo de dados corrompidos de vez em quando -. Back-up regularmente

Answer 5

O motor ACE / Jet é um grande pedaço de software, mas, ao mesmo tempo que era concebido para suportar múltiplos usuários, na verdade, apoiando vários usuários na prática, não é um dos seus pontos fortes. A gota d'água para mim é o lugar onde, em seguida, a segurança em nível de usuário removido (ULS) do motor: Acho que posso imaginar uma situação simples banco de dados onde todos os usuários terão os mesmos privilégios (acesso ou seja administrador para todas do banco de dados objetos), mas IMO que não está a apoiar vários usuários bem, em comparação com, digamos, MS SQL Server.

Answer 6

Sim, suporta o acesso de múltiplos (isto é, um pequeno grupo de trabalho de tamanho, número) dos usuários em um compartilhamento de arquivo de rede. No entanto, a arquitetura de compartilhamento de arquivos não é simplesmente ideal para apoiar a escrita simultânea em um arquivo por vários usuários. Um sistema de banco de dados cliente / servidor (SQL Server, etc.) geralmente oferece melhor desempenho, segurança e confiabilidade.

Answer 7

Como um administrador de sistema, por favor, não use Acesso para qualquer coisa multi-usuário. Faça o que Jeff Fritz sugere e usar um banco de dados que é projetado para acesso multi-usuário. Você pode pensar que seu pequeno aplicativo só vai ser compartilhado entre algumas pessoas, mas eu garanto que ele vai ter uma centena de usuários e cinquenta novos recursos até o final do ano. E se aqueles são todos Access, em vez de VB / SQL Express, seus Ops pessoas vão invadir a sua casa uma noite e cortar sua garganta.

O acesso não é um aplicativo cliente-servidor, e oferece muito pouco na maneira de backup / restore, ou qualquer que seja a automação. para não mencionar a interface e o DB está muito intimamente ligado ... por isso, se você quiser transformar isso em uma aplicação web, ou fazer quaisquer mudanças sérias, seu mundo será preenchido com dor.

Answer 8

Isso já foi feito tantas vezes por tantos engenheiros de software genérico em que vi um .mdb ir corrupto em uma situação de multi usuário. Se tantos desenvolvedores acesso especialista experiente pode obtê-lo direito, como eu estou inclinado a acreditar, então nós generalistas deve estar fazendo algo errado e que algo deve ser bastante fundamental ainda não óbvio para muitos de nós para fugir da coisa gritando 'Never again!' Então, se você se considera um experiente desenvolvedor Acesso especialista (ou você sabe como encontrar um), em seguida, ir para ele. Mas se você é um generalista ou usuário casual procura de uma extremidade traseira leve então eu sugiro que você procurar outro local (SQL Server é bom IMO).

Answer 9

Se os usuários podem esperar o dobro do tempo para uma aplicação com metade dos recursos que eles querem, então não use Access.

Answer 10

Jet não tem a lógica de bloqueio sofisticada necessária para suportar cenários multi-usuário. Você pode começar afastado com usá-lo se sua aplicação é principalmente lê e baixa contenção.

Já vi sites suportar muitos usuários, mas eu recomendaria SQL Express, a menos que você tem uma razão convincente para escolher Jet.

Answer 11

Eu posso dizer por experiência dolorosa que Jet 3 / 3.5 não era confiável. Eu vi isso falhar com freqüência sob carga leve e quando havia acidentes arriscou corrupção de dados. Ela costumava ser extremamente sensíveis a quaisquer problemas de energia, qualquer cliente bater contra ela (mesmo a interface do usuário vinculado ao mdb), e quaisquer problemas de LAN. Versões mais recentes do Jet pode ser melhor, mas a mudança para Sql Server é claramente o caminho a percorrer na minha opinião para outra coisa senão a entrada de dados trivial com um pequeno número de usuários. SQL Express é gratuito e você fazer qualquer coisa realmente não perder, especialmente se você estiver UI está em .Net, ao invés de acesso.

EDIT:. Microsoft não acho que você deve confiar em Jet 4 seja

De: http://support.microsoft.com/kb/303528

Microsoft Jet não se destina para uso com aplicativos de alta-tensão de servidor, aplicações de servidor de alta concorrência, ou 24 horas por dia, sete dias de aplicações de servidor semana. Isso inclui aplicativos de servidor, como aplicativos da Web, aplicações de comércio, aplicações transacionais e aplicativos de servidor de mensagens. Para estes tipos de aplicações, a melhor solução é mudar para um sistema verdadeiro cliente / baseado em servidor de banco de dados, como o Microsoft Data Engine (MSDE) ou Microsoft SQL Server. Quando você usa o Microsoft Jet em aplicações de alta tensão, como o Microsoft Internet Information Server (IIS), você pode experimentar qualquer um dos seguintes problemas: corrupção de dados problemas de estabilidade, como o IIS falhando ou travando falha súbita ou o fracasso persistente do driver para conectar a um banco de dados válido que requer re-iniciar o serviço IIS

Answer 12

apenas verificar se o arquivo de bloqueio db (como .ldb) está lá ou não. Se ele estiver lá, alguém está acessando o arquivo. Se ele não estiver lá, neste momento não há ninguém acessar esse arquivo e você pode prosseguir. Caso contrário, aguarde quando esse arquivo (.ldb) não é mais existente.

Answer 13

Se você usar um servidor de terminal, o desempenho é muito bom. Temos mais soluções até 50 usuários ao mesmo mdb Access. O desenvolvimento é muito rápido e fácil implantação.

Problemas:

• todos podem copiar dados mdb
• sem direitos de acesso
• procedimentos de armazenamento limitado
• optimize (compressa e reparação) só é possível com nenhum banco de dados de utilização de dados
• limite de 2 GB!