Aufbau eines Auditing-Systems; MS Access Frontend auf SQL Server Backend

Question

Also im Grunde baue ich eine App für meine Firma und es muss mit MS Access gebaut werden und es muss auf SQL Server gebaut werden.

Ich habe die meisten Pläne erstellt, aber es fällt mir schwer, einen Weg zu finden, mit dem Auditing-System umzugehen.

Da es nur intern verwendet wird und Sie die db nicht von außerhalb des Gebäudes berühren können, verwenden wir kein Anmeldesystem, da das Programm erst dann verwendet wird, wenn sich ein Benutzer bereits in unserem System angemeldet hat internes Netzwerk über Active Directory. Wenn wir das wissen, verwenden wir a system to detect automatically the name of the Active Directory user und entscheiden mit ihren Berechtigungen in einer der DB-Tabellen, was sie tun können oder was nicht.

Also die eigentliche Audit-Tabelle wird 3 Spalten haben (dieses Design kann sich ändern, aber für diese Frage ist es egal); wer (Active Directory-Benutzer), wann (Zeitpunkt des Hinzufügens/Löschens/Bearbeitens), was (was wurde geändert)

Meine Frage ist, wie soll ich damit umgehen. Idealerweise weiß ich, dass ich einen Trigger verwenden sollte, so dass es unmöglich ist, die Datenbank zu aktualisieren, ohne dass ein Audit protokolliert wird, aber ich weiß nicht, wie ich den Active Directory-Benutzer auf diese Weise erreichen könnte. Eine Alternative wäre es, es direkt in die Access-Quelle zu codieren, so dass bei jeder Änderung eine INSERT-Anweisung ausgeführt wird. Offensichtlich ist das fehlerhaft, wenn etwas mit Access passiert oder die Datenbank von etwas anderem berührt wird, wird das Audit nicht protokolliert.

Alle Ratschläge, Beispiele oder Artikel, die mir helfen könnten, würden sehr geschätzt werden!

Answer 1

Wie viele Benutzer der App wird es geben? Gibt es die Möglichkeit, Windows-Authentifizierung für SQL-Authentifizierung zu verwenden?

Aktualisiert: Wenn Sie jedem Benutzer eine SQL-Anmeldung (Windows integriert) geben können, können Sie den angemeldeten Benutzer mit der SYSTEM_USER-Funktion abholen.

Answer 2

Funktioniert das für Sie?

select user_name(),suser_sname() 

---

Doh! Ich habe vergessen, meinem Code zu entkommen.

Answer 3

Es sollte

seine

select user name(),suser sname() 

ersetzen Räume mit Unterstrichen

Answer 4

Wenn Sie SSPI in Ihrer Verbindungszeichenfolge zu Sql geben, ich denke, Ihre Windows-Anmeldeinformationen zur Verfügung gestellt werden.

Answer 5

müssen Sie mit integrierten Sicherheit verbinden aka vertrauenswürdige Verbindung sehen (http://www.connectionstrings.com/?carrier=sqlserver)

Answer 6

Ich habe versucht, mit Zugang zu spielen ein bisschen, um zu sehen, ob ich einen Weg für Sie finden kann. Ich denke, dass Sie eine neue Datenquelle zu Ihrer SQL-Tabelle angeben können, und Windows NT-Authentifizierung als Ihren Verbindungstyp auswählen.

Answer 7

Sure :)

Es sollte einen Abschnitt in Access „Externe Daten“ genannt werden (ich bin eine neue Version von Access ausgeführt wird, so dass die Menüwahl könnte anders sein).

Bilden Sie dies, es sollte eine Option geben, um eine ODBC-Verbindung anzugeben.

Ich bekomme eine Option zum Verknüpfen mit der Datenquelle durch Erstellen einer verknüpften Tabelle.

Ich erstellte dann eine Machine-Datenquelle. Ich wählte SqlServer aus der Dropdown-Liste. Wenn ich dann auf Weiter klicke, werde ich gefragt, wie ich mich authentifizieren möchte.

Answer 8

CREATE TRIGGER testtrigger1 
ON testdatatable 
AFTER update 
AS 
BEGIN 
    INSERT INTO testtable (datecol,usercol1,usercol2) VALUES (getdate(),user_name(),suser_sname()); 
END 
GO 

Answer 9

Ok, es funktioniert hier. Ich sehe meine Windows-Anmeldedaten, wenn ich meine Tabellen aktualisiere. Also, ich wette, wir haben einen Schritt verpasst. Lassen Sie mich eine 1,2,3 Sequenz von dem, was ich getan habe, zusammenstellen und vielleicht können wir herausfinden, wo das für Sie bricht.

---

1. Erstellen Sie eine neue MS Access Datenbank (leer)
2. Klicken Sie auf den Abschnitt Tabellen
3. externe Daten auswählen
4. Pick-ODBC-Datenbank
5. Pick-Link zur Datenquelle durch eine verknüpfte Tabelle erstellen
6. Maschinendatenquelle auswählen
7. Auswahl Neu ...
8. Systemdatenquelle
9. Wählen Sie SQL Server aus der Liste und klicken Sie auf Weiter, Fertig stellen.
10. Geben Sie der neuen Datenquelle einen Namen und eine Beschreibung und wählen Sie (lokal) für den Server. Weiter klicken.
11. Wählen Sie "Mit Windows NT-Authentifizierung mit der Netzwerk-Login-ID". Weiter klicken.
12. Überprüfen Sie die Standarddatenbank auf und wählen Sie die Datenbank aus. Weiter klicken. Klicken Sie auf Fertig stellen.
13. Testen Sie die Datenquelle.
14. Wählen Sie die Tabelle aus, der der Trigger zugeordnet ist, und klicken Sie auf OK.
15. Öffnen Sie die Tabelle in Access und ändern Sie einen der Einträge (der Trigger nicht ausgelöst auf Einfügen, nur Update)
16. Select * aus dem Audit-Tabelle

Answer 10

Wir haben auch ein Datenbanksystem, das ist wird ausschließlich innerhalb der Organisation verwendet und verwendet Windows NT-Logins. Diese Funktion gibt den aktuellen Benutzernamen zurück:

CREATE FUNCTION dbo.UserName() RETURNS varchar(50) 
AS 
    BEGIN 
    RETURN (SELECT nt_username FROM master.dbo.sysprocesses WHERE spid = @@SPID) 
    END 

Sie können diese Funktion in Ihren Triggern verwenden.

Answer 11

Meine Lösung wäre, Access die Daten mit verknüpften Tabellen nicht ändern zu lassen.

Ich würde nur die Benutzeroberfläche in Access erstellen und eine ADO-Verbindung zum Server mithilfe von Windows in der Verbindungszeichenfolge authentifiziert erstellen. Kompilieren Sie die Anwendung als dbe, um den VB-Code zu schützen.

Ich würde keine SQL-Anweisung ausgeben, aber ich würde gespeicherte Prozeduren aufrufen, um die Änderungen in der Datenbank durchzuführen, und den Überwachungsprotokolleintrag in einer atomaren Transaktion erstellen.

Die Benutzeroberfläche (Access) muss nicht die inneren Arbeiten auf dem Server kennen. Sie müssen lediglich die gespeicherten Prozeduren anfordern und aktualisieren/einfügen/löschen, die Sie für diesen Zweck erstellen würden. Der Server sollte die Arbeit übernehmen.

Abrufen eines Datensatzes mit ADO mithilfe einer Ansicht mit dem Hinweis NOLOCK im Server implementiert und diese Daten in Access für lokale Anzeige zwischenspeichern. Oder rufen Sie einen einzelnen Datensatz ab und sperren Sie nur diese Zeile zum Bearbeiten.

Mit verknüpften Tabellen werden Ihre Benutzer sich gegenseitig sperren.

Mit ADO-Verbindungen können Sie ODBCs nicht auf jedem einzelnen Client festlegen.

Erstellen Sie eine Tabelle, um den Serverstatus festzulegen. Ihre Anwendung wird es vor jeder Aktion überprüfen. Sie können es verwenden, um den Server für die Anwendung zu schließen, falls Sie Änderungen oder Wartungsarbeiten durchführen müssen.

Der Zugriff ist ein großartiges Werkzeug. Aber es sollte nur mit seinen lokalen Daten umgehen und darf sich nicht mit dem wertvollen Server anlegen.