Dans un projet Access (ADP), avec une base de données SQL, quelles sont les autorisations minimales requises pour l'accès pour pouvoir mettre à jour les dossiers retournés d'une vue lié à une forme, encore empêcher un SELECT direct sur la table sous-jacente? Par exemple:autorisations minimales requises pour une requête actualisable (projet Access)
Tableau: Table1 Colonnes: ID, Column1, Column2, Column3, Column4
Vue: View1
SELECT ID, Column1, Column2, Column3 FROM Table1 WHERE Column1 = 'Something'
En tant que propriétaire de la base de données, ou dans le rôle db_owner (ou rôles db_datareader, db_datawriter), les enregistrements peuvent être mis à jour via Access lorsqu'il est lié à la vue. Toutefois, si l'utilisateur n'en est pas membre, l'enregistrement ne peut pas être mis à jour via Access. Je SELECT accordé, UPDATE-View1 et renié SELECT à Table1 et permis UPDATE à Table1 (en cas ayant UPDATE sur une vue ne fonctionne pas). J'ai aussi renié UPDATE-Column1 que je ne veux pas les utilisateurs à mettre à jour cette colonne.
Si je me connecte à la base de données SQL (avec SQL Server Management Studio) avec ces autorisations de jeu, je peux mettre à jour les dossiers de la vue, mais dans Access je ne peux pas. Pourquoi est-ce? Je ne sais pas quelles requêtes Access émet pour mettre à jour un enregistrement afin de déterminer pourquoi il échoue.
Edit:
sur pas encore trouvé un moyen de savoir ce que les autorisations d'accès doit faire mise à jour sans SELECT .. SQL Profiler ne démontraient pas de cause évidente du message 'recordset pas actualisable.
Je ne l'ai jamais utilisé ADPs, mais l'une des nombreuses plaintes à leur sujet que je me souviens est que, dans certaines circonstances, ADO court-circuite votre point de vue (et vos paramètres de sécurité qui y sont) et essaie de faire mettre à jour les tables sous-jacentes directement. Je ne pense pas que les circonstances exactes étaient les mêmes que celles que vous décrivez, mais cela pourrait valoir la peine d'être examiné. –