Configuration D'une base de données MS-Access pour accès multi-utilisateurs

je trouve les réponses à cette question problématique, confuse et incomplète, donc je vais faire un effort pour faire mieux.

Q1: Comment Pouvons-nous nous assurer que l'utilisateur en écriture peut apporter des modifications aux données de la table alors que d'autres utilisateurs utilisent les données? Les lecteurs mettent-ils des verrous sur les tables? Est-ce que l'utilisateur d'écriture doit mettre des serrures sur la table? Access fait-il cela pour nous ou devons-nous le coder explicitement?

personne n'a vraiment répondu de façon complète à cette question. Le les informations sur le réglage des serrures dans les options D'accès n'ont rien à voir avec le verrouillage en lecture ou en écriture. No Locks vs. All Records vs. Edited Record est la façon dont vous définissez le verrouillage des enregistrements par défaut pour les Écritures.

• pas de serrures signifie que vous utilisez le verrouillage optimiste, ce qui signifie que vous autorisez plusieurs utilisateurs à éditer l'enregistrement et ensuite les informer après le fait si l'enregistrement a changé depuis qu'ils ont lancé leurs propres éditions. Le verrouillage optimiste est ce que vous devriez commencer avec car il nécessite pas de codage pour l'implémenter, et pour les petites populations d'utilisateurs, il ne pose presque jamais de problème.

• tous les enregistrements signifient que la table entière est verrouillée chaque fois qu'une édition est lancée.

• Edited Record signifie que moins d'enregistrements sont verrouillés, mais qu'il s'agisse ou non d'un seul enregistrement ou de plus d'un enregistrement dépend du fait que votre base de données est configurée pour utiliser le niveau de verrouillage des enregistrements (ajouté pour la première fois dans Jet 4) ou le niveau de verrouillage de la page. Franchement, je n'ai jamais pensé il vaut la peine de le configurer au niveau de l'enregistrement de verrouillage, verrouillage optimiste prend soin de la plupart des problèmes.

on pourrait penser que vous voulez utiliser un niveau record de verrouillage pessimiste, mais le fait est que dans la grande majorité des applications, deux utilisateurs ne éditent presque jamais le même enregistrement. Maintenant, évidemment, certains types d'applications peut-être des exceptions, mais si j'ai couru dans une telle application, je serais probablement essayer d'ingénieur à la refonte du schéma de sorte qu'il serait très rare pour deux utilisateurs d'éditer le même enregistrement (généralement en allant à une certaine forme d'édition transactionnelle à la place, où les changements sont faits en ajoutant des enregistrements, plutôt que d'éditer les données existantes).

maintenant, pour votre question, il y a un certain nombre de façons de restreindre certains utilisateurs à la lecture seule et d'accorder à d'autres des privilèges d'écriture. La sécurité au niveau de l'utilisateur du Jet était prévue à cette fin et fonctionne bien dans la mesure où il s'agit d'une "sécurité" pour toute définition significative de la terme. En général, tant que vous utilisez une boutique de données Jet/ACE, la meilleure sécurité que vous obtiendrez est celle fournie par Jet ULS. C'est fissurable, Oui, mais vos utilisateurs commettraient une infraction en la brisant, donc ça pourrait être suffisant.

j'aurais tendance à ne pas mettre en œuvre des scénarios du tout et à la place simplement architecte les formes d'édition de données de sorte qu'ils ont vérifié la connexion de Windows de l'utilisateur et a fait les formes en lecture seule ou en écriture en fonction de ce que les utilisateurs sont censés obtenir dont l'accès. Que vous souhaitiez ou non enregistrer l'appartenance à un groupe dans une table de données, ou maintenir des groupes de sécurité Windows à cette fin, c'est à vous de décider. Vous pouvez également utiliser un fichier Jet workgroup pour le traiter, et fournir un système différent.fichier mdw pour les utilisateurs en écriture. Les utilisateurs en lecture seule se connecteraient de manière transparente en tant qu'administrateur, et ceux connectés en tant qu'administrateur ne se verraient accorder qu'un accès en lecture seule. Les utilisateurs d'écriture se connecteraient comme un autre nom d'utilisateur (de manière transparente, dans le raccourci que vous leur fournissez pour lancer l'application, sans fournir de mot de passe), et qui serait utilisé pour configurer les formulaires comme lire ou écrire.

Si vous utilisez Jet ULS, il peut devenir vraiment poilue. Il s'agit de verrouiller toutes les tables en lecture seule (ou peut-être même pas cela) et d'utiliser ensuite les requêtes RWOP pour fournir l'accès aux données. Je n'ai fait qu'une seule application de ce genre en 14 ans de développement de L'accès professionnel.

pour résumer mes réponses aux parties de votre question:

Comment pouvons-nous nous assurer que l'utilisateur d'écriture peut apporter des modifications aux données de table tandis que d'autres utilisateurs utilisent les données?

je recommande de le faire dans l'application, en paramétrant les formulaires à lire/seulement ou modifiables à l'exécution en fonction de l'ouverture de session de l'utilisateur. L'approche la plus simple est de mettre vos formes en lecture seule et le changement modifiable pour l'écriture des utilisateurs lorsqu'ils ouvrent le formulaire.

les lecteurs mettent-ils des serrures sur les tables?

pas dans un sens significatif. Jet / ACE does have lire serrures, mais ils sont là uniquement dans le but de maintenir l'État pour les vues individuelles, et pour rafraîchir les données pour l'utilisateur. Ils ne verrouillent pas les opérations d'écriture de n'importe quelle sorte, bien que le overhead de les suivre ralentit théoriquement les choses vers le bas. Il ne suffit pas de s'inquiéter.

est-ce que l'utilisateur d'écriture doit mettre des serrures sur la table?

accès en combinaison avec Jet / ACE fait cela pour vous automatiquement, en particulier si vous choisissez le verrouillage optimiste que votre défaut. Le point clé ici est que les applications D'accès sont databound, de sorte que dès qu'un formulaire est chargé, l'enregistrement a un verrou de lecture, et dès que l'enregistrement est édité, si oui ou non il est en écriture-verrouillé pour les autres utilisateurs est déterminé par si vous utilisez un verrouillage optimiste ou pessimiste. Encore une fois, C'est le genre de chose dont L'accès prend soin pour vous avec ses comportements par défaut dans les formes liées. Vous ne vous en souciez pas jusqu'au moment où vous rencontrez des problèmes.

Accès faire cela pour nous ou devons-nous explicitement ce code?

en gros, à part le réglage de l'éditabilité à l'exécution (selon qui a accès en écriture), il n'y a pas de codage nécessaire si vous utilisez le verrouillage optimiste. Avec un verrouillage pessimiste, vous ne pouvez pas!--45--> de coder, mais vous en aurez presque toujours besoin, car vous ne pouvez pas simplement laisser l'utilisateur Bloqué avec les comportements par défaut et les messages d'erreur.

Q2: y a-t-il des problèmes courants avec les mouvements D'accès MS" que nous devrions être au courant?

Jet / ACE a le soutien pour les transactions de commit / rollback, mais il n'est pas clair pour moi si c'est ce que vous voulez dire dans cette question. En général, je n'utilise pas les transactions sauf pour maintenir l'atomicité, par exemple, lors de la création d'une facture, ou en faisant n'importe quelle mise à jour qui implique plusieurs tables. Il fonctionne sur la façon dont vous vous y attendez, mais n'est pas vraiment nécessaire pour la grande majorité des opérations dans une application D'accès.

peut-être un des problèmes ici (en particulier à la lumière de la première question) Est que vous ne pouvez pas tout à fait comprendre que L'accès est conçu pour créer des applications avec des données liées aux formulaires. "Transactions" est un sujet d'une grande importance pour les applications libres et apatrides (par exemple, basé sur le navigateur), mais pour les applications liées aux données, l'édition et la sauvegarde tout se passe de manière transparente.

pour certains types d'opérations cela peut être problématique, et parfois il est approprié d'éditer des données dans L'accès avec des formulaires non liés. Mais c'est très rarement le cas, dans mon expérience. Ce n'est pas que je n'utilise pas de formulaires non reliés -- j'en utilise beaucoup pour les dialogues et autres -- c'est juste que mes applications ne sont pas modifier tableaux de données avec formulaires non liés. Sans presque aucune exception, toutes mes applications éditent des données avec des formulaires liés.

maintenant, les formes non liées sont en fait assez faciles à implémenter dans Access (particulièrement si vous nommez vos contrôles d'édition de la même façon que les champs sous-jacents), mais aller avec les formes d'édition de données non liées est vraiment manquer le point D'utilisation de L'accès, qui est que la reliure est tout fait pour vous. Et le principal inconvénient d'aller unbound est que vous perdez tous les événements de forme de niveau record, tels que OnInsert, BeforeUpdate et ainsi de suite.

T3. Pouvons-nous travailler sur des formulaires, des questions, etc. alors qu'ils sont utilisés? Comment Pouvons-nous" programmer " sans gêner les utilisateurs?

C'est une des questions qui a été bien abordée. Toutes les applications d'accès multi-utilisateurs ou répliquées doivent être divisées, et la plupart des applications mono-utilisateurs devraient l'être aussi. C'est une bonne conception et rend également les applications plus stables, car seules les tables de données finissent par être ouvertes par Plus d'un utilisateur à la fois.

T4. Quels paramètres dans MS Access ont une influence sur la façon dont les choses sont gérées?

"les Choses?"Quelles choses?

Q5. Notre arrière-plan est principalement dans Oracle, Où Est accès différent dans la manipulation de plusieurs utilisateurs? Y a-t-il des "niveaux d'isolement" dans L'accès?

je ne sais pas tout ce qui concerne spécifiquement Oracle (aucun de mes clients ne pouvait se le permettre même s'ils le voulaient), mais Demander une comparaison de L'accès et Oracle trahit un malentendu fondamental quelque part le long de la ligne.

l'Accès est un outil de développement d'applications.

Oracle est un serveur de base de données de puissance industrielle.

pommes et oranges.

maintenant, bien sûr, accéder aux navires avec un moteur de base de données par défaut, à l'origine appelé Jet et maintenant révisé et renommé ACE, mais il existe de nombreux niveaux où L'accès à la plate-forme de développement peut être entièrement découplé de Jet/ACE, le moteur de base de données par défaut.

dans ce cas, vous avez choisi D'utiliser un Jet/ACE back end, qui sera probablement très bien pour les petites populations d'utilisateurs, i.e., moins de 25. Jet / ACE peut également être amende jusqu'à 50 ou 100, en particulier lorsque seuls quelques-uns des utilisateurs simultanés ont la permission d'écrire. Alors que la limite de 255 utilisateurs dans Jet/ACE inclut à la fois les utilisateurs en lecture seule et en écriture, le nombre d'utilisateurs d'écriture qui contrôle vraiment Combien d'utilisateurs simultanés vous pouvez soutenir, et dans votre cas, vous avez une application avec la plupart des utilisateurs en lecture seule, de sorte qu'il ne devrait pas être très difficile de concevoir une bonne application qui n'a pas de problèmes avec le dos.

fondamentalement, je pense que votre expérience Oracle est susceptible de vous conduire à mal comprendre comment développer dans Access, où l'approche attendue est de lier vos formulaires à recordsources qui sont mis à jour sans besoin d'écrire du code. Maintenant, pour des raisons d'efficacité, c'est une bonne idée de lier vos formes à des sous-ensembles d'enregistrements, plutôt qu'à des tables entières, mais même avec une table entière dans le recordsource derrière une forme d'édition de données, L'Accès va être assez efficace dans l'édition des tables Jet/ACE (le vieux mythe de tirer la table entière à travers le fil est toujours là) tant que vos tables de données sont efficacement indexées.

Enregistrer le verrouillage est quelque chose que vous surtout ne devriez pas avoir à s'inquiéter de la, et un de les raisons pour cela sont dues à l'édition liée, où la forme sait ce qui se passe dans le fond à tout moment (bien, à des intervalles d'environ une seconde, l'intervalle de rafraîchissement par défaut). C'est-à-dire, ce n'est pas comme une page web où vous récupérez une copie des données et postez ensuite vos modifications au serveur dans une transaction complètement sans rapport avec l'opération de récupération de données originale. Dans un environnement lié comme Access, le fichier de verrouillage sur le fichier de données back-end va toujours garder la trace du fait que quelqu'un a la notice de montage. Cela empêche les modifications de l'utilisateur de piétiner les modifications de quelqu'un d'autre, parce que L'accès connaît l'état et informe l'utilisateur. Tout cela se produit sans aucun codage de la part du développeur et est l'un des grands avantages du modèle d'édition liée (en dehors de ne pas avoir à écrire de code pour poster les éditions).

pour tous ceux qui sont des programmeurs de base de données expérimentés familiers avec d'autres plateformes qui viennent pour accéder pour la première fois, je vous suggère fortement d'utiliser Access comme un utilisateur final. Essayez toutes les fonctionnalités de pointage et de clic. Exécutez le formulaire et report wizards et vérifier les résultats qu'ils produisent. Je ne peux pas garantir qu'elles démontrent toutes de bonnes pratiques, mais elles démontrent clairement les hypothèses par défaut qui sous-tendent la façon dont L'accès est censé être utilisé.

si vous vous retrouvez à écrire beaucoup de code, alors vous manquez probablement le point d'accès.