2010-01-12 7 views
0

Compte tenu de la mise en place:MS Access 2007 - Identifier les utilisateurs et sur cette base de limiter l'accès aux données

  • Ms Access application divisée en Front End et Back End = les deux natifs MS Access
  • Front End se compose de formes seulement - ce sera la seule façon d'accéder aux données
  • front End copie distribuée à chaque machine utilisateur (merci pour les réponses à this question)

I besoin de mettre en œuvre le scénario suivant:

  • demande Ms Access avec < 20 utilisateurs,
  • chaque utilisateur est affecté à 1 à 10 projets,
  • lorsque l'utilisateur ouvre l'accès MS, il ne doit être présenté avec les données relatives au projet (s) il est affecté à

Ainsi, par exemple, nous avons les utilisateurs:

  • John
  • Owen

John est affecté à des projets A, B, D. Lorsque John se connecte, il ne peut voir que les données liées aux projets A, B, D. Quand Owen journaux dans ce qu'il peut voir que B, D

John et Owen peuvent accéder à l'application en même temps

tables connexes dans le Back End

  • utilisateur
  • projet
  • userProject - lie le (s) utilisateur (s) au (x) projet (s) dans de nombreuses relations.Chaque utilisateur peut être affecté à un ou plusieurs projets, un ou plusieurs utilisateurs peuvent travailler sur un projet.

je suis tombé sur this solution databasedev.co.uk qui utilise essentiellement une forme cachée pour stocker les informations des utilisateurs en cours et en utilisant ensuite ce pour filtrer les données sur d'autres formes.

Voici donc ma question:

Serait-ce la solution recommandée? Y a-t-il de meilleures options? Je pensais que je pourrais utiliser une table sur le Front End au lieu de la forme cachée par exemple.

Répondre

1

Editer Re-commentaire
Je ne vois pas pourquoi vous ne devriez pas maintenir une table d'utilisateurs dans le back-end avec une table de jointure de l'utilisateur, projet qui peut être utilisé pour filtrer les projets.L'utilisateur actuel peut être obtenu avec le code si vous utilisez le nom de réseau (http://www.mvps.org/access/api/api0008.htm), il peut être stocké dans un champ caché sur le formulaire, ce qui serait utile pour définir le formulaire pour les projets pertinents, ou vous pouvez stocker le nom d'une propriété de base de données personnalisée (http://wiki.lessthandot.com/index.php/Custom_Database_Properties_Creation_and_Use)

Le code ci-dessous s'applique à la recherche du nombre d'utilisateurs connectés.

Vous pouvez utiliser des schémas ADO spécifiques au fournisseur. Vous devez passer une connexion valide, par exemple:

ADOUserList Currentproject.Connection 


    Public Sub ADOUserList(oConn As ADODB.Connection) 
    Dim rs As ADODB.Recordset 
     Set rs = oConn.OpenSchema(adSchemaProviderSpecific, , "{947bb102-5d43-11d1-bdbf-00c04fb92675}") 
     Debug.Print rs.GetString 
     rs.Close 
    End Sub 

Plus d'informations: http://msdn.microsoft.com/en-us/library/aa155436.aspx

+0

Remou, s'il vous plaît corrigez-moi si je me trompe mais je crois que cela me donnerait la liste des utilisateurs en cours. Ce n'est pas la question. Je demande une solution qui permettrait de filtrer les données affichées à l'utilisateur par le Front End en fonction de l'affectation de l'utilisateur à un projet donné. – kristof

+0

Excuses, j'ai mal lu votre question que 20 utilisateurs se sont connectés, plutôt que 20 utilisateurs disponibles. – Fionnuala

+0

Je ne vois pas pourquoi vous ne devriez pas maintenir la table dans le back-end avec une table de jointure de l'utilisateur, projet qui peut être utilisé pour filtrer les projets. – Fionnuala

1

J'ai un semblable, si un peu plus complexe, la situation. Dans mon cas, les utilisateurs sont affectés à des groupes d'utilisateurs, qui ont des autorisations différentes sur les objets Access (formulaires, rapports, etc.). Ils ont aussi des projets auxquels ils sont affectés, et des préférences. Tables:

user

user_group

user_pref

project

user_project

Je reste toutefois utiliser une forme cachée (session) qui contient des informations de session sur l'utilisateur cette' s actuellement connecté. Par exemple: id_utilisateur, nom_utilisateur, sous-formulaire des projets affectés, préférences (par exemple, "Projet en cours"). Enfin, un module basSession contient toutes les fonctions dont j'ai besoin get ou set l'une des informations de session sous la forme cachée, par exemple gfSession_GetUserID().

HTH

+0

merci, cela semble intéressant. Au moins semblable à l'approche d'application web standard que je serais plus familier avec. Je peux effectivement utiliser cette approche – kristof

+0

Oui, j'ai utilisé le concept 'session' de mon propre développement LAMP. Pour info, j'utilise un IDE d'application web appelé CodeCharge Studio (en utilisant PHP) que j'ai trouvé très similaire à Access, avec des constructeurs de requêtes, des fenêtres de propriétés etc ... – maxhugen

0

Soyez conscient que dans la configuration actuelle, il n'y a aucun moyen d'une méthode pour «identifier les utilisateurs et sur cette base limitent l'accès aux données. Si toutes les données résident dans un fichier Access partagé, vos utilisateurs peuvent simplement ouvrir la base de données principale et parcourir toutes les données. La seule façon de limiter réellement l'accès de vos utilisateurs aux données consiste à utiliser un serveur de base de données.

Si vous voulez accéder à Access, je vous suggère de créer des requêtes pour toutes les tables (importantes) et d'utiliser ces requêtes dans les formulaires. Incluez une instruction WHERE dans la requête qui limite la sortie à ce que l'utilisateur peut afficher. Vous pouvez le faire en modifiant le code SQL complet à l'ouverture de la base de données ou en incluant une variable globale dans la partie WHERE de la requête et en définissant cette variable sur l'ID utilisateur actuel.

Questions connexes