Wie kann ich meine MS-SQL-Datenbank für meine Benutzer sperren und dennoch über ODBC darauf zugreifen?

Question

Ich habe eine MS-Access-Anwendung, die über eine ODBC-Verbindung auf eine MS-SQL-Datenbank zugreift.Ich versuche, meine Benutzer zu zwingen, die Daten zu aktualisieren nur über den Anwendungsteil, aber es ist mir egal, ob sie die Daten direkt oder über ihre eigene benutzerdefinierte MS-Access-Datenbank lesen (sie verwenden sie zum Erstellen von Ad-hoc-Berichten).

Was ich suche, ist eine Möglichkeit, die Daten nur dann bearbeitbar zu machen, wenn sie die kompilierte .mde-Datei verwenden, die ich an sie verteile.Ich weiß, dass ich die Daten nur für die allgemeine Bevölkerung lesen und für ausgewählte Benutzer bearbeiten kann.

Gibt es eine Möglichkeit, MS-SQL dazu zu bringen, die Daten nur dann bearbeitbar zu machen, wenn sie über mein vorgefertigtes MDE darauf zugreifen?

Dachte, gibt es eine Möglichkeit, MS-Access dazu zu bringen, sich als anderer Benutzer bei der Datenbank anzumelden (oder den Login zu ändern, sobald die Verbindung hergestellt ist)?

---

@Jake,
Ja, es werden Formulare verwendet.Was ich tun möchte, ist, den Benutzer einmal zu wechseln, wenn mein Launchpad-/Hauptmenü-Formular angezeigt wird.

@Peter,
Das ist tatsächlich die Richtung, in die ich gehe.Was ich noch nicht festgelegt habe, war, wie ich auf diese zweite ID umsteigen soll.Ich mache mir keine großen Sorgen, dass das Passwort ausgespäht wird, die Benutzer sind alle intern und in einem internen LAN.Wenn sie dieses Passwort erschnüffeln können, können sie sicherlich auch das für meine privilegierte ID erschnüffeln.

@niemand im Allgemeinen,
Im Moment ist es Sicherheit durch Dunkelheit.Ich habe den Benutzern eine spezielle .mdb-Datei für die Berichterstellung gegeben, mit der sie Daten lesen, aber nicht aktualisieren können.Sie wissen nicht, wie man die Tabellen über die ODBC-Verbindung erneut verknüpft.Ein etwas besser mit MS-Access/DB vertrauter Benutzer könnte das, was ich getan habe, in Sekundenschnelle umgehen – und es gibt ein paar, die sich vorstellen, DBA zu sein, also werden sie es irgendwann herausfinden.

Answer 1

Es gibt eine Möglichkeit, die bei internen Benutzern effektiv ist, aber gehackt werden kann.Sie erstellen für jeden Benutzer zwei IDs.Eine davon ist eine Berichts-ID, die nur Lesezugriff hat.Dies ist die ID, die dem Benutzer bekannt ist:Fred / meinpasswort

Die zweite ist eine ID, die Aktualisierungen durchführen kann.Diese ID ist Fred_app / mypassword_mangled.Sie melden sich mit Fred bei Ihrer App an.Wenn Ihre Anwendung auf Daten zugreift, verwendet sie die Anwendungs-ID.

Das lässt sich zwar riechen, ist aber für viele Anwendungen ausreichend.

Answer 2

Ermöglicht Ihre App verknüpfte Tabellenaktualisierungen oder erfolgt die Verarbeitung über Formulare?Klingt so, als wäre Ihre Idee, einen zentralen Benutzer mit unterschiedlichen Rollen zu verwenden, der richtige Weg.Ja, Sie könnten den Benutzer ändern, aber das führt möglicherweise zu mehr Codierung, und sobald Sie anfangen, mehr und mehr Code hinzuzufügen, klingen andere Lösungen (gespeicherte Prozeduren usw.) möglicherweise einladender.