Trigger verhindet löschen eines Datensatzes

[VizeTE]

mmm...es ist leider nicht meine Entscheidung welche Datenbank eingesetzt wird also werde ich wohl noch eine Weile an IB4 festhalten (müssen).

[MagicAndre1981]

Dann pack den Code zum Datum einfügen in das BeforePost-Event der BDE-Komponente, dann brauchst du keinen Trigger. Ist nicht ganz sauber, aber probier das mal.

André

[VizeTE]

Zitat von MagicAndre1981:

Dann pack den Code zum Datum einfügen in das BeforePost-Event der BDE-Komponente, dann brauchst du keinen Trigger. Ist nicht ganz sauber, aber probier das mal.

Theoretisch sollte das gehen aber das ist leider auch noch nicht was ich suche da ich gern die Serverzeit in dem Datumsfeld hätte und nicht die Zeit auf dem Client.

[Jelly]

Zitat von Hansa:

Siehe dieses Beispiel hier. Beim Erstellen der Tabelle kann ich doch noch nicht wissen, daß ich in 1 Stunde um 20:19:55,4 einen neuen Datensatz anlege ! Der Trigger überwacht das ganze deshalb und merkt sich, daß da die Zeit festgehalten werden muß, auch wenn ichs vergesse. 8)

Jetzt versteh ich erst was du damit meintest. Hab mich vielleicht schlecht ausgedrückt. Aber du kannst auch als default Wert das aktuelle Datum nehmen, zumindest unter dem MSSQL Server kein Problem:

SQL-Code:

create table Daten (
ID int,
Datum datetime  null default getdate())
go

Muss Dir jetzt nur noch die Funktion aus dem IB holen, die dir das aktuelle Datum liefert.

[VizeTE]

Zitat von Jelly:

Aber du kannst auch als default Wert das aktuelle Datum nehmen, zumindest unter dem MSSQL Server kein Problem

Ich bezweifle, dass das Interbase kann. Aber selbst wenn benötige ich diese Funktion ja auch nach dem ändern des DS. Da hilft der default-Wert leider nicht weiter.

[Hansa]

@Viez, bist du immer noch dran die DB zu zerhackstückeln ?

SQL-Code:

/******************************************************************************/
/****              Generated by IBExpert 04.10.2005 18:10:28               ****/
/******************************************************************************/

SET SQL DIALECT 3;

SET NAMES ISO8859_1;

SET TERM ^ ;

CREATE TRIGGER TABLE1_AUO FOR TABLE1
ACTIVE AFTER UPDATE POSITION 0
as
begin
  update TABLE1 set
    LETZTEAENDERUNG = current_timestamp
  where (ID = old.ID) and ((LETZTEAENDERUNG is null) or
        (LETZTEAENDERUNG <> current_timestamp));
end
^

SET TERM ; ^

Der Trigger protokolliert sekundengenau, wann zuletzt an der DB an diesem einen betroffenen Datensatz etwas geändert wurde. Es wäre ein leichtes, dabei noch festzuhalten welcher User es war usw. Wo liegt das Problem ? Natürlich kann man das nicht schon beim Erzeugen der Table machen und deshalb sind die Default-Werte fehl am Platze.

[VizeTE]

Zitat von Hansa:

Der Trigger protokolliert sekundengenau, wann zuletzt an der DB an diesem einen betroffenen Datensatz etwas geändert wurde. Es wäre ein leichtes, dabei noch festzuhalten welcher User es war usw. Wo liegt das Problem ?

Das funktioniert prinzipiell, ja. Das Problem liegt aber darin wenn ich diesen DS, nachdem "Post" aufgerufen wurde, nochmal ändere. Dann bekomme ich folgende Fehlermeldung: (wie Eingangs beschrieben)

Datensatz kann nicht gesperrt werden, da der Datensatz von einen anderen Benutzter geändert wurde.
(EDBEngineError)

Die einzige Erklärung die ich mir denken kann ist, daß der Trigger als ein anderer User läuft. Aber so richtig kann ich das auch nicht glauben. Wenn ich ein Rollback mache weiß die DB ja auch welche Trigger dazugehören.

[dfried]

Das Problem ist doch einfach, dass die BDE vor dem löschen nochmal nachschaut, ob sich der Datensatz inzwischen geändert hat. Und da der Trigger den Datensatz nochmal geändert hat meint die BDE eben es war noch ein anderer Benutzer an dem Datensatz dran.

Du kannst jetzt folgendes machen:

1. in deiner TTable oder TQuery den UpdateMode auf upWhereKeyOnly setzen (vorausgesetzt du hast einen Primary Key)

2. nach dem Insert/Update des Datensatzes gleich einen Refresh auf diesen Datensatz machen, das wäre eh die bessere Lösung, dann siehst du die vom Trigger generierten Werte auch gleich auf dem Client

Danach dürfte dem Löschen nix mehr im Weg stehen.

Gruß
Daniel

[VizeTE]

Hallo dfried.

Die erste Lösung funktioniert schon mal. Danke.
Wenn ich den Update-Modus "upWhereKeyOnly" verwende muß ich dann noch irgendwas beachten? Soweit ich die Hilfe verstande habe bekomme ich keine Probleme solange ich den Key nicht ändere. Gibts da noch mehr Stolpersteine?

Die zweite Lösung scheint mir aber auch vernünftiger. Ich verwende ein TQuery. Wie kann ich da einen Primary Key verwenden? Die zu Grunde liegende Tabelle besitzt einen Primary Key aber wie ich den in die Abfrage bekomme weiß nicht.

[Jelly]

Zitat von VizeTE:

Die zweite Lösung scheint mir aber auch vernünftiger. Ich verwende ein TQuery. Wie kann ich da einen Primary Key verwenden? Die zu Grunde liegende Tabelle besitzt einen Primary Key aber wie ich den in die Abfrage bekomme weiß nicht.

Was hat dein Primary Key mit Delphi zu tun Ich versteh dein Problem nicht.