Configuration d'une base de données MS-Access pour un accès multi-utilisateurs
Nous envisageons de "développer" une petite base de données MS-Access avec quelques tables, formulaires et requêtes pour plusieurs utilisateurs. (L'utilisation d'un back-end différent en est une autre, mais une option à plus long terme qui n'est malheureusement pas acceptable actuellement.)
La plupart des utilisateurs seront en lecture seule, mais il y aura quelques (actuellement un ou deux) utilisateurs qui doivent pouvoir effectuer des modifications (tandis que les utilisateurs en lecture seule utilisent également la base de données). Nous ne sommes pas tellement préoccupés par les aspects de sécurité, mais plutôt par certains des problèmes suivants:
- Comment pouvons-nous nous assurer que l'utilisateur en écriture peut apporter des modifications aux données de la table pendant que d'autres utilisateurs utilisent les données? Les utilisateurs en lecture mettent-ils des verrous sur les tables? L'utilisateur en écriture doit-il mettre des verrous sur la table? Access le fait-il pour nous ou devons-nous le coder explicitement?
- Y a-t-il des problèmes communs avec les "transactions MS Access" dont nous devrions être conscients?
- Pouvons-nous travailler sur des formulaires, des requêtes, etc. pendant leur utilisation? Comment "programmer" sans gêner les utilisateurs?
- Quels paramètres de MS Access ont une influence sur la façon dont les choses sont gérées?
- Notre expérience est principalement dans Oracle, où Access est-il différent dans la gestion de plusieurs utilisateurs? Existe-t-il des "niveaux d'isolement" dans Access?
Tous les conseils ou pointeurs vers des articles utiles seraient grandement appréciés.
Je trouve que les réponses à cette question sont problématiques, déroutantes et incomplètes, je vais donc 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 pendant que d'autres utilisateurs utilisent les données? Les utilisateurs en lecture mettent-ils des verrous sur les tables? L'utilisateur en écriture doit-il mettre des verrous sur la table? Access le fait-il pour nous ou devons-nous le coder explicitement?
Personne n'a vraiment répondu à cette question de façon complète. Les informations sur la définition des verrous dans les options d'accès n'ont rien à voir avec le verrouillage en lecture et en écriture. No Locks vs. All Records vs. Edited Record est la façon dont vous définissez le verrouillage d'enregistrement par défaut pour WRITES.
Aucun verrouillage signifie que vous utilisez le verrouillage OPTIMISTIC, ce qui signifie que vous autorisez plusieurs utilisateurs à modifier l'enregistrement, puis à les informer après coup si l'enregistrement a changé depuis qu'ils ont lancé leurs propres modifications. Le verrouillage optimiste est ce que vous devriez commencer car il ne nécessite aucun codage pour l'implémenter, et pour les petites populations d'utilisateurs, il ne pose pratiquement jamais de problème.
Tous les enregistrements signifie que la table entière est verrouillée chaque fois qu'une modification est lancée.
L'enregistrement modifié signifie que moins d'enregistrements sont verrouillés, mais qu'il s'agisse ou non d'un seul enregistrement ou de plusieurs enregistrements selon que votre base de données est configurée pour utiliser le verrouillage au niveau de l'enregistrement (ajouté pour la première fois dans Jet 4) ou le verrouillage au niveau de la page. Franchement, je n'ai jamais pensé qu'il valait la peine de mettre en place un verrouillage au niveau de l'enregistrement, car un verrouillage optimiste s'occupe de la plupart des problèmes.
On pourrait penser que vous souhaitez utiliser un verrouillage pessimiste au niveau de l'enregistrement, mais le fait est que dans la grande majorité des applications, deux utilisateurs ne modifient presque jamais le même enregistrement. Maintenant, évidemment, certains types d'applications pourraient être des exceptions à cela, mais si je rencontrais une telle application, j'essaierais probablement de la concevoir en repensant le schéma afin qu'il soit très rare que deux utilisateurs modifient le même enregistrement (généralement en passant à une forme de modification transactionnelle à la place, où des modifications sont apportées en ajoutant des enregistrements, plutôt qu'en modifiant les données existantes).
Maintenant, pour votre vraie question, il existe plusieurs 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 Jet était prévue à cet effet et fonctionne très bien dans la mesure où il s'agit de "sécurité" pour toute définition significative du terme. En général, tant que vous utilisez un magasin de données Jet/ACE, la meilleure sécurité que vous obtiendrez est celle fournie par Jet ULS. C'est craquable, oui, mais vos utilisateurs commettraient une infraction fable en la cassant, donc cela pourrait être suffisant.
J'aurais tendance à ne pas implémenter Jet ULS du tout et à la place, à simplement architecturer les formulaires de modification des données de sorte qu'ils vérifient la connexion Windows de l'utilisateur et rendent les formulaires en lecture seule ou inscriptibles en fonction des utilisateurs censés obtenir quel accès. À vous de décider si vous souhaitez ou non enregistrer l'appartenance à un groupe dans une table de données ou gérer les groupes de sécurité Windows à cette fin. Vous pouvez également utiliser un fichier de groupe de travail Jet pour y faire face et fournir un fichier system.mdw différent 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 en écriture se connecteraient sous 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 en lecture ou en écriture.
Si vous utilisez Jet ULS, il peut devenir vraiment poilu pour bien faire les choses. Cela implique de verrouiller toutes les tables en lecture seule (ou peut-être même pas cela), puis d'utiliser des requêtes RWOP pour fournir l'accès aux données. Je n'ai pas fait mais une telle application dans mes 14 années de développement professionnel d'accès.
Pour résumer mes réponses aux parties de votre question:
Comment pouvons-nous nous assurer que l'utilisateur en écriture peut apporter des modifications aux données de la table pendant que d'autres utilisateurs utilisent les données?
Je recommanderais de le faire dans l'application, de définir les formulaires en lecture/uniquement ou modifiables lors de l'exécution en fonction de la connexion de l'utilisateur. L'approche la plus simple consiste à définir vos formulaires en lecture seule et à modifier en modifiables pour les utilisateurs d'écriture lorsqu'ils ouvrent le formulaire.
Les utilisateurs en lecture mettent-ils des verrous sur les tables?
Pas dans un sens. Jet/ACE possède des verrous de lecture, mais ils ne sont là que pour maintenir l'état des vues individuelles et pour actualiser les données pour l'utilisateur. Ils ne bloquent aucune opération d'écriture d'aucune sorte, bien que la surcharge de leur suivi ralentisse théoriquement les choses. Ce n'est pas suffisant de s'inquiéter.
L'utilisateur en écriture doit-il mettre des verrous sur la table?
Access en combinaison avec Jet/ACE le fait automatiquement pour vous, en particulier si vous choisissez le verrouillage optimiste par défaut. Le point clé ici est que les applications Access sont liées aux données, donc dès qu'un formulaire est chargé, l'enregistrement a un verrou en lecture, et dès que l'enregistrement est modifié, qu'il soit verrouillé en écriture pour les autres utilisateurs est déterminé par que vous utilisiez un verrouillage optimiste ou pessimiste. Encore une fois, c'est le genre de chose dont Access s'occupe pour vous avec ses comportements par défaut dans les formulaires liés. Vous ne vous inquiétez de rien jusqu'à ce que vous rencontriez des problèmes.
Access le fait-il pour nous ou devons-nous le coder explicitement?
Fondamentalement, à part définir la possibilité de modification au moment de l'exécution (en fonction de qui dispose d'un accès en écriture), aucun codage n'est nécessaire si vous utilisez un verrouillage optimiste. Avec le verrouillage pessimiste, vous n'avez pas à coder , mais vous en aurez presque toujours besoin, car vous ne pouvez pas simplement laisser l'utilisateur coincé avec le comportements par défaut et messages d'erreur.
Q2: Existe-t-il des problèmes communs avec les "transactions MS Access"?
Jet/ACE prend en charge les transactions de validation/annulation, mais je ne sais pas si c'est ce que vous voulez dire dans cette question. En général, je n'utilise pas de transactions, sauf pour maintenir l'atomicité, par exemple, lors de la création d'une facture ou de toute mise à jour impliquant plusieurs tables. Il fonctionne de la manière attendue, mais n'est pas vraiment nécessaire pour la grande majorité des opérations dans une application Access.
Peut-être que l'un des problèmes ici (en particulier à la lumière de la première question) est que vous ne comprenez pas très bien qu'Access est conçu pour créer des applications avec des données liées aux formulaires. Les "transactions" sont un sujet d'une grande importance pour les applications non liées et sans état (par exemple, basées sur un navigateur), mais pour les applications liées aux données, l'édition et la sauvegarde se font de manière transparente.
Pour certains types d'opérations, cela peut être problématique et il est parfois approprié de modifier les données dans Access avec des formulaires non liés. Mais c'est très rarement le cas, d'après mon expérience. Ce n'est pas que je n'utilise pas de formulaires non liés - j'en utilise beaucoup pour les dialogues et autres - c'est juste que mes applications ne modifient pas tableaux de données avec formulaires non liés. Sans presque aucune exception, toutes mes applications modifient les données avec des formulaires liés.
Maintenant, les formulaires non liés sont en fait assez faciles à implémenter dans Access (en particulier si vous nommez vos contrôles d'édition de la même manière que les champs sous-jacents), mais le fait d'utiliser des formulaires d'édition de données non liés manque vraiment d'utiliser Access, à savoir que la liaison est tout est fait pour vous. Et le principal inconvénient de ne pas être lié est que vous perdez tous les événements de formulaire au niveau de l'enregistrement, tels que OnInsert, BeforeUpdate, etc.
Q3. Pouvons-nous travailler sur des formulaires, des requêtes, etc. pendant leur utilisation? Comment "programmer" sans gêner les utilisateurs?
C'est l'une des questions qui ont été bien traitées. Toutes les applications Access multi-utilisateurs ou répliquées doivent être divisées, et la plupart des applications mono-utilisateur doivent l'être également. C'est une bonne conception et rend également les applications plus stables, car seuls les tableaux de données finissent par être ouverts par plusieurs utilisateurs à la fois.
Q4. Quels paramètres de MS Access ont une influence sur la façon dont les choses sont gérées?
"Des choses?" Ce que les choses?
Q5. Notre expérience est principalement dans Oracle, où Access est-il différent dans la gestion de plusieurs utilisateurs? Existe-t-il des "niveaux d'isolement" dans Access?
Je ne sais rien spécifiquement d'Oracle (aucun de mes clients ne pouvait se le permettre même s'ils le voulaient), mais demander une comparaison entre Access et Oracle trahit un malentendu fondamental quelque part le long de la ligne.
Access 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, Access est livré 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 auxquels Access la plate-forme de développement peut être entièrement découplée de Jet/ACE, le moteur de base de données par défaut.
Dans ce cas, vous avez choisi d'utiliser un backend Jet/ACE, ce qui conviendra probablement très bien aux petites populations d'utilisateurs, c'est-à-dire moins de 25 ans. Jet/ACE peut également convenir jusqu'à 50 ou 100, en particulier lorsque seul un peu d'utilisateurs simultanés ont une autorisation d'écriture. Alors que la limite de 255 utilisateurs dans Jet/ACE inclut à la fois les utilisateurs en lecture seule et en écriture, c'est le nombre d'utilisateurs en écriture qui contrôle vraiment le nombre d'utilisateurs simultanés que vous pouvez prendre en charge, et dans votre cas, vous avez une application avec principalement la lecture -seulement les utilisateurs, il ne devrait donc pas être extrêmement difficile de concevoir une bonne application qui n'a aucun problème avec le back-end.
Fondamentalement, je pense que votre expérience Oracle vous amène probablement à mal comprendre comment développer dans Access, où l'approche attendue est de lier vos formulaires à des sources d'enregistrement mises à jour sans avoir besoin d'écrire du code. Maintenant, pour des raisons d'efficacité, il est judicieux de lier vos formulaires à des sous-ensembles d'enregistrements, plutôt qu'à des tables entières, mais même avec une table entière dans la source d'enregistrements derrière un formulaire d'édition de données, Access va être assez efficace pour éditer Jet/Tables ACE (le vieux mythe de tirer toute la table sur le fil est toujours là) tant que vos tables de données sont indexées efficacement.
Le verrouillage d'enregistrement est quelque chose que vous ne devriez surtout pas avoir à vous inquiéter, et l'une des raisons à cela est à cause de l'édition liée, où le formulaire sait ce qui se passe en arrière-plan à tout moment (enfin, à intervalles d'environ seconde d'intervalle, l'intervalle de rafraîchissement par défaut). C'est-à-dire que ce n'est pas comme une page Web où vous récupérez une copie des données puis publiez vos modifications sur le serveur dans une transaction complètement déconnectée de l'opération de récupération des données d'origine. Dans un environnement lié comme Access, le fichier de verrouillage du fichier de données principal gardera toujours la trace du fait que quelqu'un a ouvert l'enregistrement pour le modifier. Cela empêche les modifications d'un utilisateur de piétiner les modifications d'une autre personne, car Access connaît l'état et informe l'utilisateur. Tout cela se passe sans aucun codage de la part du développeur et est l'un des grands avantages du modèle d'édition lié (en plus de ne pas avoir à écrire de code pour publier les modifications).
Pour tous ceux qui sont des programmeurs de bases de données expérimentés et familiers avec d'autres plates-formes qui viennent pour la première fois dans Access, je suggère fortement d'utiliser Access comme un utilisateur final. Essayez toutes les fonctionnalités pointer-cliquer. Exécutez les assistants de formulaire et de rapport et vérifiez les résultats qu'ils produisent. Je ne peux pas garantir que tous démontrent de bonnes pratiques, mais ils démontrent définitivement les hypothèses par défaut derrière la façon dont Access est destiné à être utilisé.
Si vous vous retrouvez en train d'écrire beaucoup de code, alors vous manquez probablement le point d'accès.
La première chose à faire (si ce n'est pas déjà fait) est de diviser votre base de données en un front-end (avec tous les formulaires/rapports, etc.) et un back-end (avec toutes les données). La deuxième chose est de configurer le contrôle de version sur le front-end.
La façon dont je l'ai fait dans beaucoup de mes bases de données est de faire exécuter aux utilisateurs une petite base de données "cavaliers" pour ouvrir la base de données principale. Ce cavalier fait les choses suivantes
• Vérifie si l'utilisateur a la base de données sur son lecteur C
• S'ils ne s'installent pas et ne s'exécutent pas
• S'ils le font, vérifiez quelle version ils ont
• Si les numéros de version ne correspondent pas, copiez la dernière version
• Ouvrez la base de données
L'ensemble de ce processus de vérification prend normalement moins d'une demi-seconde. En utilisant ce modèle, vous pouvez effectuer tout votre développement sur une base de données distincte, puis lorsque vous êtes prêt à "publier", vous placez simplement le nouveau mde sur le partage réseau et la prochaine fois que l'utilisateur ouvre le cavalier, la dernière version est copiée.
Il y a aussi d'autres choses à penser dans la base de données multi-utilisateurs et il peut être utile de vérifier les erreurs courantes telles que la liaison d'un formulaire à une table entière, etc.
Le verrouillage de table ou d'enregistrement est disponible dans Access pendant l'écriture de données. Vous pouvez contrôler le verrouillage d'enregistrement par défaut via Outils | Options | Onglet Avancé:
- Pas de serrures
- Tous les enregistrements
- Enregistrement modifié
Vous pouvez définir cela sur les verrous d'enregistrement d'un formulaire ou dans votre code DAO/ADO pour des besoins spécifiques.
Les transactions ne devraient pas être un problème si vous les utilisez correctement.
Meilleure pratique: séparez vos tables de tous vos autres codes. Donnez à chaque utilisateur sa propre copie du fichier de code, puis partagez le fichier de données sur un serveur réseau. Travaillez sur une copie "test" du code (et un lien vers un fichier de données de test), puis mettez à jour les fichiers de code individuels de l'utilisateur séparément. Si vous devez apporter des modifications au fichier de données (ajouter des tables, des colonnes, etc.), vous devrez demander à tous les utilisateurs de quitter l'application pour effectuer les modifications.
Voir les autres réponses pour la comparaison Oracle.
je pense qu'Access est le meilleur choix pour votre cas. Mais vous devez diviser la base de données, voir: http://accessblog.net/2005/07/how-to-split-database-into-be-and-fe.html
• Comment pouvons-nous nous assurer que l'utilisateur en écriture peut apporter des modifications aux données de la table pendant que d'autres utilisateurs utilisent les données? Les utilisateurs en lecture mettent-ils des verrous sur les tables? L'utilisateur en écriture doit-il mettre des verrous sur la table? Access le fait-il pour nous ou devons-nous le coder explicitement?
il n'y a pas de verrous en lecture, sauf si vous les placez explicitement. Utilisez simplement "No Locks"
• Y a-t-il des problèmes communs avec les "transactions MS Access" dont nous devrions être conscients?
ne devrait pas être un problème avec 1-2 utilisateurs d'écriture
• Pouvons-nous travailler sur des formulaires, des requêtes, etc. pendant leur utilisation? Comment "programmer" sans gêner les utilisateurs?
si vous divisez la base de données - alors pas de problème pour travailler sur la conception FE.
• Quels paramètres de MS Access ont une influence sur la façon dont les choses sont gérées?
Que voulez-vous dire?
• Notre expérience est principalement dans Oracle, où Access est-il différent dans la gestion de plusieurs utilisateurs? Existe-t-il des "niveaux d'isolement" dans Access?
aucun niveau d'isolement dans l'accès. BTW, vous pouvez ensuite déplacer les données vers Oracle et conserver l'accès frontal, si vous avez beaucoup d'utilisateurs et une grande base de données.
Access est une excellente base de données multi-utilisateurs. Il possède de nombreuses fonctionnalités intégrées pour gérer la situation multi-utilisateurs. En fait, il est très populaire car c'est une excellente base de données multi-utilisateurs. Il y a une limite supérieure sur le nombre d'utilisateurs pouvant tous utiliser la base de données en même temps pour effectuer des mises à jour et des modifications - en fonction de la compétence du développeur en matière d'accès et de la conception de la base de données - de 20 utilisateurs à environ 50 utilisateurs. Certaines bases de données d'accès peuvent être créées pour gérer jusqu'à 50 utilisateurs simultanés, tandis que beaucoup d'autres peuvent gérer 20 ou 25 utilisateurs simultanés mettant à jour la base de données. Ces chiffres ont été observés pour des bases de données qui sont utilisées depuis plusieurs années et ont été discutées à plusieurs reprises dans les groupes de discussion d'accès.
La façon correcte de créer des applications Microsoft Access client/serveur dans lesquelles les données sont stockées dans un SGBDR consiste à utiliser la méthode Linked Table. Cela garantit que l'isolation des données et la concurrence sont maintenues entre l'application cliente Microsoft Access et les données du SGBDR sans logique et code de programmation supplémentaires et inutiles, ce qui rend la maintenance plus difficile et augmente le temps de développement.
voir: http://claysql.blogspot.com/2014/08/normal-0-false-false-false-en-us-x-none.html
J'ai trouvé le protocole SMB2 introduit dans Vista pour verrouiller les bases de données d'accès. Il peut être désactivé par le regedit suivant:
Éditeur de registre Windows version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters] "Smb2" = dword: 00000000