![]() |
AW: Trigger auf Datenbankebene?
CREATE TRIGGER wirft da aber doch hoffentlich einen Fehler, wenn man einen zweiten Trigger erstellen will? :stupid:
Meistens hat man doch in etwa sowas:
SQL-Code:
Bei einigen DBMS kann man da aber auch Parameter bei den Trigger-Funktionen nutzen.
CREATE FUNCTION TriggerFunction() ...;
CREATE TRIGGER TriggerName ON Table ... DO TriggerFunction();
SQL-Code:
Und die selbe Trigger-Funktion kann man auch an mehrere Tabellen hängen.
CREATE FUNCTION TriggerFunction(Param VARCHAR) ...;
CREATE TRIGGER TriggerName ON Table ... DO TriggerFunction('abc'); Es gibt fast immer irgendwelche virtuellen Datenbank-Schema-Tabellen, wo man eine Liste aller aktuell existierenden Tabellen auslesen kann und dann entweder clientseitig oder DB-seitig über einen EXECUTE-Befehl nacheinander die vielen CREATE TRIGGER zusammensetzen und ausführen.
SQL-Code:
CREATE FUNCTION TriggerFunction() ...;
CREATE TRIGGER TriggerName ON TableA ... DO TriggerFunction(); CREATE TRIGGER TriggerName ON TableB ... DO TriggerFunction(); CREATE TRIGGER TriggerName ON TableC ... DO TriggerFunction(); |
AW: Trigger auf Datenbankebene?
|
AW: Trigger auf Datenbankebene?
Zitat:
Delphi-Quellcode:
unit FDQueryInterposer;
interface type TFDQuery = class(FireDAC.Comp.Client.TFDQuery) protected procedure DoBeforePost; override; end; implementation procedure TFDQuery.DoBeforePost; begin { hier bei Bedarf die entsprechenden Felder setzen } inherited; end; end. |
AW: Trigger auf Datenbankebene?
Zitat:
wenn ich das richtig im Kopf habe, arbeitest Du häufig mit Postgres? Da kann man beliebige Triggerfunktionen an den Trigger hängen, auch für mehrere Trigger/Tabellen die gleiche Triggerfunktion. Hab ich neulich noch für eine Log Funktion/Werteänderung gemacht. Das geht aber so easy nicht mit jeder Datenbank. Um es straight forward zu lösen, müsste m.E. tatsächlich ein Usermapping mit einer Tabelle, die aktive Sitzungen notiert, erfolgen. Daraus könnte sich dann ein Insert/Update/ Trigger pro Tabelle bedienen (delete fällt ja weg bei der Konstruktion). Ich habe bei dem erwähnten Log Mechnismus oben, nach der Erstellung der Trigger "blinde Updates" (alter Wert = neuer Wert) über alle relevanten Daten laufen lassen und so nachträglich mit etwas Handarbeit "historische" Logdaten für initiales Insert und Update (=StatusQuo) erzeugt. Nicht geloggte Userdaten usw. lassen sich damit natürlich im Nachhinein nicht erfinden. Aber man hat dennoch für künftiges Reporting einen einheitlichen Stand. In einem reinen C/S System mit nur einem Client (einer Art) kann man natürlich auch über den Client arbeiten. Hier kann man auch problemlos weitere Daten verwenden, Rechnername usw. bei Mehrfachanmeldung oder was man so braucht. |
AW: Trigger auf Datenbankebene?
Eine BeforePost-Methode kann man mehreren Datenbankkomponenten zuweisen.
Beispiel:
Delphi-Quellcode:
Nachteil: Wird, am Programm vorbei, direkt auf der Datenbank gearbeitet oder mit anderen Clients, fehlen die im BeforePost gesetzten Informationen natürlich.
type
TForm1 = class(TForm) qryAnschriften: TZQuery; // oder sonstein genutzter Komponententyp qryRechnungen: TZQuery; // oder sonstein genutzter Komponententyp ... procedure AnyTableBeforePost(DataSet: TDataSet); ... procedure TForm1.FormCreate(Sender: TObject); begin qryAnschriften.BeforePost := AnyTableBeforePost; qryRechnungen.BeforePost := AnyTableBeforePost; ... end; procedure TForm1.AnyTableBeforePost(DataSet: TDataSet); begin DataSet.FieldByName('Username').AsString := DeineGetUserNameFunktionOderVariabelOderSowas; DataSet.FieldByName('Datum').AsString := Now; end; |
AW: Trigger auf Datenbankebene?
Zitat:
![]() Hier klingt es sogar danach, dass man auch direkt ganze SQL-Statements da ausführen lassen kann, anstatt nur eine TriggerFunktion aufzurufen. |
AW: Trigger auf Datenbankebene?
Zitat:
Gruß K-H |
AW: Trigger auf Datenbankebene?
Ja, das ist wohl so. Aber eine solche Forderung geht aus der Frage des TE nicht hervor. Wahrscheinlich wurde die Anforderung erst später angefragt.
Grundsätzlich ist die Verwendung eines Datenbank-Triggers hier der bessere Weg, wenn man diese Daten grundsätzlich bei jedem Insert- oder Update-Statement verwenden möchte. Aber dann benötigt der TE eine Tabelle mit den Benutzern, gegen die sich die Anwender anmelden müssen, damit er die Namen ziehen kann. War auch mein erster Gedanke, aber ist wohl beim TE nicht vorgesehen oder war nicht geplant. Wenn ich es richtig verstanden habe, werden DB-User angemeldet, die über eine Rolle verfügen. Und ja, er muss die Trigger für jede Tabelle anlegen, ein Aufwand, den er nicht treiben wollte. Über das Event muss er das dann aber auch machen, kann aber wie oben beschrieben eine Standard-Routine verwenden, um den Aufwand zu reduzieren. Grüße Mikhal |
AW: Trigger auf Datenbankebene?
Zitat:
Wenn es wasserdicht sein soll, müssen solche Operationen auf dem DB Server erfolgen. Wenn ich ein C/S System so definiere, dass mein (Delphi)Client den einzigen Zugriff hat (und diesen Zustand auch erfolgreich sicherstellen kann), dann kann ich natürlich hier alle möglichen Mätzchen machen, von Logging bis Business Logic. Sobald mehr als ein System auf die DB durchgreift (vor allem schreibend), bin ich natürlich gekniffen. Theoretisch entgleitet das bereits, wenn ich einen Release Candidate des gleichen Sytems auf eine Produktivdb loslasse. Naja, ich will den Teufel nicht an die Wand malen. Wenn man weiß was man tut, ist vieles möglich. Ich hatte allerdings die Anforderung des TE so verstanden, dass er nicht alle / so viel Altdaten "nachverarbeiten" will. Aber vlt geht es darum gar nicht. Zitat:
Aber das von Dir erwähnte Verfahren kenne ich so halt von Postgres und eben nicht von Maria. |
AW: Trigger auf Datenbankebene?
Zitat:
Gruß K-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz