Comment utiliser les rôles d'application avec les projets Access et SQL Server 2000 Desktop Edition

Traductions disponibles Traductions disponibles
Numéro d'article: 308312 - Voir les produits auxquels s'applique cet article
Options avancées : nécessite codage expert, de l'interopérabilité et de compétences multi-utilisateur.

Cet article s'applique uniquement à un projet Microsoft Access (.adp).

Pour une version de Microsoft Access 2000 de cet article, voir 318816.
Agrandir tout | Réduire tout

Résumé

Cet article explique les fonctionnalités, les limitations et les solutions d'utilisation des rôles d'application de Microsoft SQL Server dans un projet Microsoft Access (ADP).

Plus d'informations

Dans SQL Server, vous pouvez créer des rôles de base de données pour administration simplifiée des autorisations dans une base de données. Au lieu d'accorder des autorisations individuelles pour chaque utilisateur séparément, vous pouvez regrouper utilisateurs avec les besoins d'autorisation même en effectuant les membres du même rôle de base de données ordinaire, puis affectant autorisations au rôle de base de données lui-même. Sauf si une autorisation spécifique est explicitement refusée ailleurs, les utilisateurs membres obtenir les autorisations accordées à ce rôle de base de données.

Bien que les rôles de base de données ordinaire soient très utile pour les situations où vous souhaitez que les utilisateurs effectuer leurs propres requêtes ad hoc ou mises à jour une base de données, elles ne sont pas toujours appropriés. Vous pouvez être amené utilisateurs uniquement certaines autorisations lorsqu'ils utilisent une application spécifique et que vous ne souhaitez pas pouvoir afficher ou modifier des données en dehors de l'application.

Une méthode qui est souvent utilisée pour contourner ce consiste à uniquement accorder les autorisations nécessaires à un compte d'utilisateur SQL Server. Les utilisateurs réels peut-être autorisations pour se connecter à une base de données mais pas afficher ou modifier les données. Après qu'un utilisateur se connecte à la base de données en utilisant le compte d'utilisateur individuel, le ADP pourrait puis par programmation reconnectez-vous en utilisant les informations d'identification du compte d'utilisateur qui possède des autorisations. Si cela peut être efficace, il n'autorise pas vous permet de distinguer les utilisateurs dans la base de données ou de déterminer quel utilisateur effectué une action particulière.

Rôles d'application sont conçus pour contourner cette limitation. Rôles d'application, contrairement aux rôles de base de données ordinaire, inutile de membres eux-mêmes. Au lieu de cela, les utilisateurs connectez-vous à une base de données SQL Server ou MSDE et se connecter à une base de données à l'aide de leurs propres informations d'identification. À ce stade, le contexte de sécurité d'un rôle d'application peut être appliquée par programmation à une connexion existante en utilisant la procédure sp_setapprole stockées. Dans SQL Server, les utilisateurs individuels sont toujours faisait la différence mais les autorisations qui sont disponibles dans une connexion spécifique sont limitées aux autorisations du rôle application. De l'utilisateur individuel autorisations, si inférieur ou supérieur, sont considérés comme plus.

Création d'un rôle d'application

Microsoft Access projets n'avez pas les outils conception visuelle pour créer des objets de sécurité de SQL Server tels que les rôles d'application. Microsoft vous recommande d'utiliser les outils clients qui sont inclus avec la version standard de SQL Server ou Microsoft Office XP Developer pour créer le rôle d'application et lui affecter des autorisations. Toutefois, vous pouvez toujours créer le rôle d'application et lui accorder les autorisations nécessaires par programmation à l'aide de Transact-SQL (T-SQL) à partir d'un ADP. Même si une étude complète de sécurité de SQL Server est en dehors de l'étendue de cet article, des informations se trouvent dans la documentation en ligne de SQL Server les étapes suivantes vous indique comment créer un rôle d'application et accorder le nouveau rôle de sélectionner les autorisations sur une table par programmation :
  1. Démarrez Access.
  2. Ouvrez le projet de Access exemple Les Comptoirs.
  3. Dans la fenêtre base de données, cliquez sur modules sous objets , puis cliquez sur Nouveau pour ouvrir un nouveau module dans l'environnement Visual Basic.

    note Dans Access 2007, cliquez sur module dans le autre groupe de l'onglet Créer .
  4. Tapez ou collez le code suivant dans le nouveau module :
    Public Function AddNewAppRole(RoleName As String, PW As String) As Boolean
    On Error GoTo EH:
    If CurrentProject.IsConnected Then
    Dim sTSQL As String
        'Create the command
    sTSQL = "EXEC sp_addapprole '" & RoleName & "','" & PW & "'"
        'Send the command
    Application.CurrentProject.Connection.Execute sTSQL
    AddNewAppRole = True
    Else
    AddNewAppRole = False
    End If
    Exit Function
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical
    AddNewAppRole = False
    End Function
    					
  5. Enregistrez le module et quittez l'environnement Visual Basic.
  6. Créer une copie de la table clients et puis enregistrez-le en tant que tNewTable . Pour ce faire, procédez comme suit :
    1. Dans la fenêtre base de données, cliquez avec le bouton droit sur la table clients , puis cliquez sur Enregistrer sous dans le menu contextuel.

      note Dans Access 2007, cliquez sur la table clients dans le volet de navigation, cliquez sur bouton Microsoft Office , pointez sur Enregistrer sous et puis cliquez sur Enregistrer l'objet sous .
    2. Dans la boîte de dialogue Enregistrer sous , tapez tNewTable dans la table « Customers » pour zone et puis cliquez sur OK .
  7. Dans la fenêtre base de données, cliquez sur formulaires sous objets , cliquez sur Nouveau et puis cliquez sur OK pour ouvrir un nouveau formulaire en mode Création.

    note Dans Access 2007, cliquez sur Mise en forme du formulaire dans le groupe formulaires de l'onglet Créer .
  8. Ajouter un bouton de commande au nouveau formulaire.
  9. Définir la propriété OnClick du nouveau bouton de commande à la procédure événementielle suivante :
    On Error GoTo EH:
    'Code only works if ADP is connected.
    If CurrentProject.IsConnected Then
        Dim bNewAppRole As Boolean, strTSQL As String
        Dim strRoleName As String, strPW As String
        strRoleName = "AppRoleName"
        strPW = "Password"
        'Call function to create app role.
        bNewAppRole = AddNewAppRole(strRoleName, strPW)
        'Test to see if it failed.
        If bNewAppRole = False Then
            Exit Sub
        End If
        MsgBox "New Application role '" & strRoleName & "' created", vbInformation
        'Create command to grant permissions.
        strTSQL = "Grant Select on tNewTable to " & strRoleName
        'Send the command.
        Application.CurrentProject.Connection.Execute strTSQL
        MsgBox "Select permissions granted on tNewTable for " & strRoleName
    Else
    MsgBox "ADP must be connected to SQL Server"
    End If
    Exit Sub
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical
    					
  10. Fermez l'environnement Visual Basic pour revenir à l'écran.
  11. Enregistrer le formulaire et puis basculez le formulaire à l' écran afficher .
  12. Cliquez sur le bouton de commande pour exécuter le code sous-jacent.

    Notez que vous recevez deux messages pour indiquer la réussite. Vous recevez un après le rôle d'application est créé et le second exemple après les nouvelle autorisations de rôle à tNewTable sont accordées.

Implémenter le rôle d'application

La complication principale lorsque vous utilisez des rôles d'application dans les projets Access est qu'Access utilise trois connexions à SQL Server pour gérer les différentes tâches. Idéalement, pour appliquer un rôle d'application au projet entier, vous devez devez exécuter sp_setapprole dans le contexte de tous les trois connexions. Les objets gérés par chaque connexion sont comme suit :

  1. Utilisé pour déterminer les objets apparaissent dans la base de données fenêtre et tâches d'administration de base de données divers.

    Utilisé pour l'ouverture de tables, vues, procédures stockées, fonctions et les sources d'enregistrement pour les formulaires et les sous-états (mais pas pour les l'état principal lui-même).

    Utilisé pour obtenir les sources d'enregistrement de zones de liste modifiable, zones de liste et rapports.
  2. Utilisé pour l'ouverture de tables, vues, procédures stockées, fonctions et les sources d'enregistrement pour les formulaires et les sous-états (mais pas pour les l'état principal lui-même).

    Utilisé pour obtenir les sources d'enregistrement de zones de liste modifiable, zones de liste et rapports.
  3. Utilisé pour obtenir les sources d'enregistrement de zones de liste modifiable, zones de liste et rapports.

Bien que connexions 2 et 3 sont accessibles assez facilement, n'est aucune méthode disponible pour exécuter la procédure stockée dans le contexte de connexion n ° 1. Heureusement, cette connexion est la moins importante des trois et facilement contournée en créant votre propre interface utilisateur (par exemple, un formulaire menu général-type) de gestion des objets de base de données au lieu de se fier à la fenêtre base de données intégrée.

La procédure suivante utilise le projet de Access échantillon Les Comptoirs pour montrer comment appliquer un rôle application contre les connexions 2 et 3 :

  1. Dans la fenêtre base de données, cliquez sur formulaires sous objets , cliquez sur Nouveau et puis cliquez sur OK pour ouvrir un nouveau formulaire en mode Création.

    note Dans Access 2007, cliquez sur Mise en forme du formulaire dans le groupe formulaires de l'onglet Créer .
  2. Ajouter une zone de liste dans le formulaire nouvellement créé et définissez la propriété Name de la zone de liste à lst_AppRole .
  3. Ajouter un bouton de commande à l'écran.
  4. Définir la propriété OnClick du nouveau bouton de commande à la procédure événementielle suivante :
    On Error GoTo EH
        'This avoids a message that no records were returned.
    DoCmd.SetWarnings False
    Dim TSQL
    TSQL = "EXEC sp_setapprole 'AppRoleName', {Encrypt N 'Password'}, 'odbc'"
        'This sets the app role on Connection #2.
    Application.CurrentProject.Connection.Execute TSQL
        'This sets the app role on Connection #3.
    lst_approle.RowSource = TSQL
    lst_approle.Requery
    DoCmd.SetWarnings True
    MsgBox "The application Role is now in effect.", vbInformation
    Exit Sub
    EH:
    MsgBox Err.Number & ": " & Err.Description, vbCritical
    					
  5. Fermez l'environnement Visual Basic pour revenir à l'écran.
  6. Enregistrer le formulaire et puis basculez le formulaire à l' écran afficher .
  7. Cliquez sur le bouton de commande pour exécuter le code sous-jacent.

    Notez qu'une boîte de message qui indique le succès s'affiche.
  8. Dans la fenêtre base de données, cliquez sur tables sous objets , puis ouvrez la table tNewTable .

    note Dans Access 2007, double-cliquez sur tNewTable table dans le volet de navigation.
  9. Modifier un enregistrement et tentez d'enregistrer les modifications.
Notez que lorsque vous essayez de valider vos modifications, vous recevez un message d'erreur sur n'a pas suffisamment d'autorisations. Ce problème se produit car vous avez attribué le nouveau rôle application autorisation sélectionner sur la table tNewTable , mais pas l'autorisation de mise à jour .

Par conception, Access affiche uniquement les objets dans cette fenêtre pour laquelle l'utilisateur a au moins sélectionner ou exécuter des autorisations. Access utilise connexion n ° 1 pour déterminer quels objets un utilisateur dispose d'autorisations pour. Après l'application de l'application rôle à la fenêtre connexions 2 et 3, la base de données affiche toujours les mêmes objets qu'auparavant, même si l'utilisateur peut n'ont plus autorisations à tous les objets ou peut avoir des autorisations à plusieurs objets qui ne sont pas affichés. Cela peut entraîner un comportement inattendu lorsque vous utilisez la fenêtre base de données.

Par exemple, lorsque vous avez ouvert la table tNewTable, il » s'affiche « que l'utilisateur dispose autorisations modifier et insérer des enregistrements. L'icône Insérer nouvel enregistrement en bas de la table est activée et l'utilisateur peut placer un enregistrement dans le mode Édition. Vous ne voyez pas n'importe quel indication visuelle pour indiquer dans le cas contraire jusqu'à ce que vous tentez de valider la modifier ou insérez, qui se traduit par un message d'erreur. Accès pense que vous disposez des autorisations lorsque réellement ne.

La solution plus efficace consiste à fournir une interface personnalisée pour l'utilisateur et non aux dépendent de la fenêtre base de données. En utilisant une interface utilisateur de menu général-type, vous pouvez contrôler exactement quels objets de l'utilisateur a accès.

Autres limitations et les considérations de sécurité

Les sous-formulaires ne fonctionne pas

Contrairement à avec les autres objets de base de données, Access ne pas toujours utiliser la même connexion pour récupérer la source de données d'un sous-formulaire. Accès fréquemment (mais pas toujours) crée une connexion nouveau à SQL Server uniquement pour gérer le jeu d'enregistrements de sous-formulaire ou à récupérer les données des champs liaison qui se connecte le sous-formulaire au formulaire principal. Car cette nouvelle connexion ne dispose pas du rôle application appliqué, une erreur d'autorisations peut être générée si vous ne disposez pas des autorisations explicites à l'objet de base de données. Malheureusement, cela signifie que n'est aucun fiable façon d'utiliser sous-formulaires dépendants lorsque des rôles d'application sont appliquées. La solution de contournement uniquement consiste à avoir indépendant entièrement sous-formulaires, avec la manipulation de données gérée par programmation. Il s'agit la limitation plus sérieuse lorsque vous utilisez des rôles d'application dans Access.

rapports ne fonctionne pas

Lorsque vous avez un objet tel qu'un tableau ou un nom d'affichage indiqué comme source enregistrement d'un état ou un sous-état, Access vérifie si l'objet est répertorié dans la fenêtre base de données avant d'extraire les données à partir de SQL Server. Étant donné que la fenêtre base de données utilise une connexion qui le rôle application appliqué n'est pas, une erreur est générée si vous n'avez pas les autorisations explicites à la source de données sous-jacente.

Pour contourner ce problème, toujours utiliser des instructions Transact-SQL comme source d'enregistrement pour les formulaires et états. Par exemple, utiliser « SELECT * à partir de NomVue » au lieu de simplement « NomVue » ou « Exec StoredProcedureName » au lieu de simplement « StoredProcedureName ». Ainsi, Access transmet les instructions Transact-SQL directement à SQL Server et extrait les données selon les autorisations du rôle application.

rôle de la base de données publique

Un rôle d'application obtient les autorisations du rôle public de base de données. Par défaut dans NorthwindCS, le rôle public dispose autorisations complets à la plupart des objets. Par conséquent, un rôle d'application est en général inefficace. Lorsque vous avez créé la table tNewTable dans la section « Création d'un rôle application », le rôle public n'a pas autorisé à la table et vous ultérieurement de voir les effets du contexte de sécurité application rôle dans cette table. Toutefois, autres tables peuvent afficher toute différence dans le rôle d'application, car le rôle public possède des autorisations à ces objets.

sécurité VBA

Étant donné que le mot de passe pour le rôle d'application est incorporé dans l'application à partir de laquelle elle est appelée, un utilisateur compétent pourra lire le nom de rôle d'application et le mot de passe à partir du code source et ensuite utiliser ces informations pour accéder à SQL Server à partir d'une autre application. Par conséquent, il est conseillé de compiler le ADP dans un fichier ADE pour que le code source ne soit pas visible. Au minimum, appliquer un mot de passe sur le projet VBA.

Références

Pour plus d'informations sur une version de Microsoft Access 2000 de cet article, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
318816 ACC2000 : Comment faire pour utiliser les rôles d'application avec des projets Access et SQL Server 2000 Desktop Engine (MSDE 2000)
Pour plus d'informations sur GRANT, consultez la documentation en ligne de SQL Server . La documentation en ligne de SQL Server est disponible au site Web de Microsoft suivant :
http://www.microsoft.com/sql/techinfo/productdoc/2000/default.asp

Propriétés

Numéro d'article: 308312 - Dernière mise à jour: jeudi 29 mars 2007 - Version: 6.2
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002
Mots-clés : 
kbmt kbexpertiseinter kbinfo kbprogramming kbadp kbvba kbhowto KB308312 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 308312
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com