Wenn dies Ihr erster Besuch hier ist,
lesen Sie bitte zuerst die Hilfe - Häufig gestellte Fragen
durch. Sie müssen sich vermutlich registrieren,
bevor Sie Beiträge verfassen können. Klicken Sie oben auf 'Registrieren', um den Registrierungsprozess zu
starten. Sie können auch jetzt schon Beiträge lesen. Suchen Sie sich einfach das Forum aus, das Sie am meisten
interessiert.
Ein Trigger wird automatisch von der DB gestartet wenn ein aktion (INSERT/DELETE/UPDATE) auf eine Tabelle durchgeführt wird.
Du wirst wenn du Parameter selbst übergeben willst mit SP's arbeiten müssen
ein Trigger hat ja Zugriff auf alle Spalten der getriggerten Tabelle. Wenn jetzt in die Tabelle entsprechende "Dummyspalten" eingefügt werden, so kann man darüber quasi Parameter übergeben.
Gruß Fal
Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.
Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!
Naja, die Idee dahinter ist, nicht physisch zu löschen, sondern das Datum und der Benutzer der Löschung zu vermerken. Mit Trigger wär's elegant gewesen, weil die Clients bzw. Middleware dann 'normale' DELETE-SQLs senden könnten. Wenn ich Historisierung einbaue, wird natürlich der Zugriff sofort komplexer und viele Vorteile von O/R-Mappern gehen verloren..
In meinen Programmen sind Login und Passwort echte Datenbankbenutzer, mit denen angemeldet wird. Der Vorteil dabei ist, ich weiß auch ohne Parameter, wer gerade eine Aktion fährt.
Beim DELETE könnte man wunderbar einen INSTEAD-OF-Trigger einsetzen, der den Datensatz, anstatt ihn zu löschen, in eine History-Tabelle schiebt und dort noch um Login und Datum/Zeit ergänzt.<br>
bye, Helmu
> In meinen Programmen sind Login und Passwort echte Datenbankbenutzer
Diesen Ansatz habe ich mir auch schon überlegt, bin aber auf zwei Probleme gestossen:
- Rollenbasierte Sicherheit.
Saubere, feine Sicherheitsmodelle (z. B. inaktive Menü-Punkte) sind damit wohl nicht machbar. Stattdessen würde, z. B. wenn der CLient einen Dialog aufbauen will eine entsprechende DB-Exception auftauchen, die dann vom Client entsprechend verarbeitet werden muss.
- LDAP.
Eigentlich habe ich vor, meine Grüppchen und Konten in einem LDAP-Verzeichnis anzulegen, das ich dann auslese, damit das möglichst zentral verwaltet werden kann. die User-Tabelle soll somit nur ID-Zuweisungen enthalten.
Da hast du allerdings recht. Ich bin mit den Möglichkeiten über die Rollen im SQL-Server und die Anmeldung über NT-Authentifizierung auch nicht zusammenkommen und habe daher alles ausprogrammiert. Dafür habe ich jetzt meine eigenen passenden Benutzergruppen mit entsprechenden Berechtigungsmöglichkeiten exakt zur Applikation passend, es gibt daher auch keine Exceptions in der Applikation und es funktioniert auf einem Standalone-PC mit einer Standard-Windows-Installation genauso wie in einem großen Netzwerk mit Aussenstellen über VPN eingebunden.
Aber wie gesagt - viel Arbeit im Clientprogramm
Comment