Configurar um DB de acesso MS para acesso multi-utilizador

Acho que as respostas a esta pergunta são problemáticas, confusas e incompletas, por isso vou fazer um esforço para fazer melhor.

Q1: Como podemos ter a certeza de que o utilizador de escrita pode fazer alterações nos dados da tabela enquanto outros utilizadores usam os dados? Os leitores colocam fechaduras nas mesas? O utilizador de escrita tem de colocar fechaduras na mesa? O Access faz isso por nós ou temos que codificar explicitamente isso?

Ninguém respondeu completamente a isto. A informação sobre a configuração dos bloqueios nas opções de acesso não tem nada a ver com o bloqueio de leitura vs. escrita. Sem bloqueios vs. todos os registos vs. registos editados é como você define o bloqueio de registos por omissão para as gravuras.

• Sem bloqueios significa que você está usando bloqueio otimista, O que significa que você permite que vários usuários para editar o registro e, em seguida, informá-los após o fato de que o registro mudou desde que eles lançaram suas próprias edições. Bloqueio otimista é o que você deve começar com como ele não requer codificação para implementá-lo, e para as populações de pequenos utilizadores raramente causa problemas.

• Todos os registros significam que toda a tabela é bloqueada a qualquer momento que uma edição é lançada.

• Registro editado significa que menos registros são bloqueados, mas se é ou não um único registro ou mais de um registro depende se seu banco de dados é configurado para usar o bloqueio de nível de registro (primeiro adicionado no Jet 4) ou bloqueio de nível de página. Francamente, nunca pensei que valesse a pena o trabalho de estabelecer um bloqueio de nível recorde., como bloqueio otimista cuida da maioria dos problemas.

Pode-se pensar que você quer usar bloqueio pessimista nível de recordes, mas o fato é que na grande maioria dos aplicativos, dois usuários quase nunca editam o mesmo registro. Agora, obviamente, certos tipos de aplicativos que podem haver exceções para isso, mas se eu me deparei com esse aplicativo, eu provavelmente tentar engenharia de distância ao redesenhar o esquema, de modo que seria muito raro que dois usuários editar o mesmo registro (geralmente por indo para alguma forma de edição transacional em vez disso, onde as alterações são feitas pela adição de registros, em vez de editar os dados existentes).

Agora, para a sua pergunta real, há uma série de maneiras de conseguir restringir alguns usuários apenas para leitura e conceder privilégios de escrita a outros. Jet user-level security was intended for this purpose and works fine as it is "security" for any meaningful definition of the term. Em geral, desde que você esteja usando um Jet / ACE data store, o melhor a segurança que vai receber é a fornecida pela Jet ULS. É quebrável, Sim, mas os seus utilizadores estariam a cometer um crime terrível ao quebrá-lo, por isso pode ser suficiente.

Eu tenderia a não implementar Jet ULS em tudo e em vez disso apenas arquitectar os formulários de edição de dados de tal forma que eles verificaram o logon do Windows do utilizador e fez os formulários apenas para leitura ou escrita, dependendo de quais os utilizadores devem obter o acesso. Se deseja ou não gravar a adesão a um grupo numa tabela de dados, ou manter os grupos de segurança do Windows para este fim depende de você. Você também pode usar um arquivo Jet workgroup para lidar com ele, e fornecer um sistema diferente.ficheiro mdw para os utilizadores de escrita. Os usuários apenas de leitura se conectariam de forma transparente como admin, e aqueles conectados como admin seriam concedidos apenas acesso de leitura. Os utilizadores de escrita ligar-se-iam como qualquer outro nome de utilizador (de forma transparente, no atalho que você lhes fornece para o lançamento do aplicativo, não fornecendo Nenhuma senha), e isso seria usado para configurar o formulários lidos ou escritos.

Se usares Jet ULS, pode tornar-se muito complicado acertar. Envolve o bloqueio de todas as tabelas como Apenas leitura (ou talvez não mesmo isso) e, em seguida, usando RWOP consultas para fornecer acesso aos dados. Não fiz mais do que uma aplicação desses nos meus 14 anos de desenvolvimento de acesso profissional.

Para resumir as minhas respostas às partes da tua pergunta:

Como podemos ter a certeza de que o write-user pode fazer alterações nos dados da tabela enquanto outros usuários usam o data?

Eu recomendaria fazer isto na aplicação, definindo os formulários para serem lidos/apenas ou editáveis à hora de execução, dependendo do logon do utilizador. A abordagem mais fácil é definir seus formulários para serem apenas de leitura e mudar para editáveis para os usuários de escrita quando eles abrem o formulário.

Os leitores colocam fechaduras nas mesas?

Não em nenhum sentido significativo. Jet / ACE tem leitura de fechaduras, mas eles estão lá apenas para a finalidade de manter o estado para visões individuais, e para refrescamento de dados para o utilizador. Eles não bloqueiam operações de escrita de qualquer tipo, embora a sobrecarga de rastreá-los teoricamente atrasa as coisas. Não é o suficiente para te preocupares.

O utilizador de escrita tem de colocar fechaduras na mesa?

O acesso em combinação com o Jet/ACE Faz isto por si automaticamente, especialmente se escolher o bloqueio optimista como o seu valor por omissão. O ponto chave aqui é que os aplicativos de acesso São databound, assim que um formulário é carregado, o registro tem um bloqueio de leitura, e assim que à medida que o registro é editado, se é ou não fechado à escrita para outros usuários é determinado se você está usando bloqueio otimista ou pessimista. Mais uma vez, este é o tipo de coisa que o Access cuida para você com seus comportamentos padrão em formas encadernadas. Você não se preocupa com nada disso até o ponto em que você encontra problemas.

O Access faz isto por nós ou temos de codificar isto explicitamente?

Basicamente, para além de ajustar a editabilidade ao tempo de execução (de acordo com quem acesso de escrita), não há codificação necessária se você estiver usando bloqueio otimista. Com bloqueio pessimista, você não tempara codificar, mas você quase sempre precisa, pois você não pode simplesmente deixar o usuário preso com os comportamentos padrão e mensagens de erro.

Q2: existem problemas comuns com as" transacções de acesso MS " de que deveríamos estar cientes?

O Jet / ACE tem suporte para transações de commit/rollback, mas não está claro para mim se é isso que quer dizer nesta pergunta. Em geral, eu não uso transações exceto para manter atomicidade, por exemplo, ao criar uma fatura, ou fazer qualquer atualização que envolva várias tabelas. Funciona da maneira que você esperaria, mas não é realmente necessário para a grande maioria das operações em um aplicativo de acesso. Talvez um dos problemas aqui (particularmente à luz da primeira pergunta) é que você não pode compreender que o acesso é projetado para criar aplicativos com dados ligados aos formulários. "Transacções" é um tópico de grande importância para aplicativos não vinculados e apps apps sem estado (por exemplo, baseados em navegador), mas para aplicativos com limite de dados, a edição e gravação de tudo acontece de forma transparente.

Para certos tipos de operações isto pode ser problemático, e ocasionalmente é apropriado editar dados no acesso com formulários não vinculados. Mas isso raramente acontece, pela minha experiência. Não é que eu não use formulários não vinculados -- eu uso muitos deles para diálogos e coisas assim -- é que meus aplicativos não editamdados quadros com formas não ligadas. Com quase nenhuma exceção, todos os meus aplicativos editam dados com formulários encadernados.

Agora, os formulários não vinculados são realmente bastante fáceis de implementar no Access( particularmente se você nomear seus controles de edição o mesmo que os campos subjacentes), mas indo com formulários de edição de dados não vinculados está realmente faltando o ponto de usar o Access, que é que a ligação é tudo feito para você. E a principal desvantagem de não ser consolidado é que você perde todos os eventos de nível recorde de forma, como OnInsert, Antes do Update e assim por diante.

Q3. Podemos trabalhar em formulários, consultas, etc. enquanto estão a ser usados? Como podemos "programar" sem estar no caminho dos usuários?

Esta é uma das questões bem abordadas. Todos os aplicativos de acesso multi-usuário ou replicado devem ser divididos, e a maioria dos aplicativos de usuário único deve ser, também. É um bom design e também torna os aplicativos mais estáveis, uma vez que apenas as tabelas de dados acabam sendo abertas por mais de um usuário de cada vez.

Q4. Qual a configuração no MS O acesso tem influência na forma como as coisas são tratadas?

"Coisas?"Que coisas?

Q5. O nosso passado está principalmente na Oracle, onde é que o acesso é diferente na manipulação de múltiplos utilizadores? Existem" níveis de isolamento " no acesso?

Não sei nada especificamente sobre a Oracle (nenhum dos meus clientes podia pagar, mesmo que quisessem), mas pedir uma comparação do Access e a Oracle trai um mal-entendido fundamental algures ao longo da linha.

Acesso é uma ferramenta de desenvolvimento de aplicações.

A Oracle é um servidor de base de dados de força industrial.

Maçãs e laranjas.

Agora, é claro, as naves de acesso com um motor de banco de dados padrão, originalmente chamado Jet E agora revisto e renomeado ACE, mas há muitos níveis em que o acesso à plataforma de desenvolvimento pode ser totalmente dissociado do Jet/ACE, o motor de banco de dados padrão. Neste caso, escolheu usar um jato / ACE, o que provavelmente será bom para pequenas populações utilizadoras, isto é, com menos de 25 anos. Jet / ACE também pode ser multa até 50 ou 100, particularmente quando apenas alguns dos usuários simultâneos têm permissão de escrita. Enquanto a 255-limite de usuários no Jet/ACE inclui somente leitura e escrita os utilizadores, é o número de escrever os usuários que realmente controla a quantidade de usuários simultâneos, você pode suportar, e no seu caso, você tem um aplicativo com maioria de somente leitura usuários, por isso oughtn não ser terrivelmente difícil para o engenheiro de um bom aplicativo que não tenha problemas com a parte de trás final.

Basicamente, eu acho que o seu fundo Oracle está provavelmente levando você a entender mal como se desenvolver no Access, onde a abordagem esperada é vincular seus formulários para gravar fontes que são atualizadas sem qualquer necessidade de escrever código. Agora, por uma questão de eficiência, é uma boa idéia ligar seus formulários a subconjuntos de registros, em vez de tabelas inteiras, mas mesmo com uma tabela inteira na fonte de registros por trás de um formulário de edição de dados, O Acesso vai ser bastante eficiente na edição de tabelas Jet / ACE (o velho mito sobre puxar toda a mesa através do fio ainda está lá fora) enquanto suas tabelas de dados são indexadas eficientemente.

O bloqueio de Registos é algo com o qual não deve ter motivos para se preocupar, e uma das razões para isso é por causa da edição limitada, onde o formulário sabe o que está a acontecer na parte de trás em todos os momentos (bem, em intervalos de um segundo, o intervalo de actualização por omissão). Isto é, não é como uma página web onde você recupera uma cópia dos dados e em seguida, postar suas edições de volta para o servidor em uma transação completamente desconectada com a operação original de recuperação de dados. Em um ambiente vinculado como o Access, o arquivo de bloqueio no arquivo de dados back-end está sempre mantendo o controle do fato de que alguém tem o registro aberto para edição. Isso impede que as edições de um usuário pisem as edições de outra pessoa, porque o Access conhece o estado e informa o usuário. Tudo isso acontece sem qualquer codificação por parte do desenvolvedor e é um dos grandes vantagens do modelo de edição encadernado (além de não ter que escrever código para postar as edições).

Para todos aqueles que são experientes programadores de banco de dados familiarizados com outras plataformas que estão vindo para acessar pela primeira vez, eu sugiro fortemente usar o acesso como um usuário final. Experimente todos os recursos do ponto e clique. Execute o formulário e informe feiticeiros e verifique os resultados que eles produzem. Não posso garantir que todos eles demonstrem boas práticas, mas eles definitivamente demonstrar as premissas por trás da forma como o acesso se destina a ser utilizado. Se estiver a escrever um monte de código, deve estar a perder o ponto de acesso.