Comment puis-je verrouiller ma base de données MS-SQL pour mes utilisateurs tout en y accédant via ODBC ?

Question

J'ai une application MS-Access qui accède à la base de données MS-SQL via une connexion ODBC.J'essaie de forcer mes utilisateurs à mettre à jour les données seulement via la partie application, mais peu m'importe s'ils lisent les données directement ou via leur propre base de données ms-access personnalisée (ils l'utilisent pour créer des rapports ad hoc).

Ce que je recherche, c'est un moyen de rendre les données modifiables uniquement s'ils utilisent le fichier .mde compilé que je leur distribue.Je sais que je peux rendre les données lues uniquement pour la population générale et modifiables pour certains utilisateurs.

Existe-t-il un moyen pour que ms-sql rende les données modifiables uniquement s'ils y accèdent via mon mode prédéfini ?

Pensé, existe-t-il un moyen d'obtenir un accès MS pour se connecter à la base de données en tant qu'utilisateur différent (ou modifier la connexion une fois connecté) ?

---

@Jake,
Oui, il utilise des formulaires.Ce que je cherche à faire, c'est simplement de le faire changer d'utilisateur une fois lorsque mon formulaire de tableau de bord/menu principal apparaît.

@Pierre,
C’est effectivement dans cette direction que je me dirige.Ce que je n'ai pas déterminé, c'est comment passer à cette deuxième pièce d'identité.Je ne suis pas tellement inquiet du fait que le mot de passe soit reniflé, les utilisateurs sont tous internes et sur un réseau local interne.S’ils peuvent détecter ce mot de passe, ils peuvent certainement détecter celui de mon identifiant privilégié.

@personne en général,
À l'heure actuelle, sa sécurité est assurée par l'obscurité.J'ai donné aux utilisateurs un fichier .mdb spécial pour créer des rapports qui leur permettront de lire les données, mais pas de les mettre à jour.Ils ne savent pas comment rétablir les liens vers les tables via la connexion ODBC.Un utilisateur un peu plus familiarisé avec ms-access/DB pourrait contourner ce que j'ai fait en quelques secondes - et quelques-uns s'imaginent être un administrateur de base de données, donc ils finiront par le comprendre.

Answer 1

Il existe un moyen de procéder qui est efficace auprès des utilisateurs internes, mais qui peut être piraté.Vous créez deux identifiants pour chaque utilisateur.L’un d’entre eux est un identifiant de rapport doté d’un accès en lecture seule.Il s'agit de l'identifiant que l'utilisateur connaît :Fred / mon mot de passe

Le second est un identifiant qui peut effectuer des mises à jour.Cet identifiant est Fred_app / mypassword_mangled.Ils se connectent à votre application avec Fred.Lorsque votre application accède aux données, elle utilise l'identifiant de l'application.

Cela peut être détecté, mais pour de nombreuses applications, cela suffit.

Answer 2

Votre application permet-elle les mises à jour de tables liées ou passe-t-elle par des formulaires ?On dirait que votre idée d'utiliser un utilisateur centralisé avec des rôles distincts est la voie à suivre.Oui, vous pouvez changer d'utilisateur, mais cela peut introduire plus de codage et une fois que vous commencez à ajouter de plus en plus de code, d'autres solutions (procédures stockées, etc.) peuvent sembler plus attrayantes.