MSSQL: Datensatz fehlt

[himitsu]

OK, dass ist dann bissl blöd.
Joar, Referenzen einfügen oder wenn's nicht geht dann mit Triggern an beiden Tabellen den Zustand prüfen.

Zitat:

Zitat von haentschman (Beitrag 1479388)

.alles im Live Betrieb. :cry:

Ja wann denn sonst?

Mehr Spannung bei der Arbeit.




Aber hey Corona ... nun hast Zeit das schnell zu machen, bis Januar, wenn wieder gearbeitet wird.

[haentschman]

Zitat:

nun hast Zeit das schnell zu machen, bis Januar, wenn wieder gearbeitet wird.

...morgen letzter Tag. :cheer: :zwinker:

[Delphi.Narium]

Eigentlich sollte es sogar im Livebetrieb möglich sein, einen Trigger zu erstellen, der das Löschen von Datensätzen verbietet:

SQL-Code:

CREATE TRIGGER trTabellennameOnDelete ON Tabellenname
FOR DELETE AS
  RAISERROR('Das Löschen von Datensätzen ist nicht zulässig!', 16, 1)
  ROLLBACK
END

Und kann heute bzw. morgen, am letzten Tag, noch erstellt werden ;-)

[himitsu]

Vergiss das IF nicht, wo geprüft wird ob Masterdaten nicht vorhanden, bzw. Detaildaten vorhanden sind.
Außerdem nicht nur beim DELETE, sondern auch beim UPDATE, wenn die "Referenzen" sich ändern. (und vielleicht beim INSERT, um ungültige Referenzen garnicht erst erstellen zu können)

Und jupp ... schnell schnell, dat schaffst schon noch. (das Wasserfall-Model ... nach mir die Sintflut)


Alternativ, wenn du das Verhalten nicht sofort ändern willst, dann nur einen Trigger, der beim Löschen die IDs/Referenzen nur in "...-DELETED" umbenennt (also im Trigger das DELETE in ein UPDATE abändern),
bzw. den Datensatz als Sicherhungskopie in eine andere Tabelle kopiert.
Dann kannst das Gelöschte schnell wiederherstellen lassen.

Oder allgemein einen Trigger, der ein Änderungslog zu wichtigen Tabellen erstellt.

[TigerLilly]

Es wird wohl Szenarien geben, wo das Löschen zulässig ist.

Wie gesagt, ev kann man das RAISERROR davon abhängig machen, ob es noch Detaildatensätze gibt. Aber wenn die Software zB zuerst den Master löscht + dann die Details, weil es keine RefIntChecks gibt, geht das so nicht.

[himitsu]

Zitat:

Zitat von TigerLilly (Beitrag 1479395)

Aber wenn die Software zB zuerst den Master löscht + dann die Details, weil es keine RefIntChecks gibt, geht das so nicht.

Bei Transaktionen kann man den Trigger eventuell erst als After-Statement oder Bevor-Commit laufen lassen, dann ist die Reihenfolge egal. (geht bei einigen DBMS)

Genauso, wie man auch bei Referenzen die Checks vorübergehend deaktivieren kann. (z.B. für einen Import in unbestimmter Reihenfolge)

[Delphi.Narium]

Mein Vorschlag geht nur erstmal dahin, dass Löschen zu verbieten.

Das man dann ggfls. auch Logiken für Sonderfälle benötigt, sollte absolut klar sein.

Es ist nur erstmal ein Workaround, um das "unmotivierte Verschwinden von Mastersätzen" zu verhindern.

Und natürlich bekommen (erstmal) Master und Detail jeweils ihren entsprechenden Trigger.

Löschen darf (laut Eingangspost) nur der Admin.

Der Trigger braucht also letztlich irgend einen Hinweis darauf, wie er den Admin erkennen kann.

Nach dem bisherigen Wissensstand scheint mir eine datenbankseitige Abhängigkeit zu fehlen, die sicherstellt, dass kein Master gelöscht werden kann, wenn es noch Details gibt.
Ob Details gelöscht werden dürfen, kann ich dem Thread momentan nicht entnehmen.

Zitat:

Zitat von haentschman

Ich bin schon der Meinung, ein Log schreiben zu müssen. (AfterDelete)

Warum nach dem Auftreten des Fehlers was ins Log schreiben?

Warum nicht im BeforeDelete 'ne Exception werfen, per MessageDLG "Willst Du wirklich?" fragen oder einfach per Cancel ... das Löschen verhindern.

Wenn ich etwas nicht will, dann versuche ich es vorher zu verhindern und nicht nachher irgendwie zu reparieren.

OK: Im BeforeDelete etwas für den Workflow sinnvolles machen und ggfls. das Löschen verhindern. Im AfterDelete protokollieren (falls denn doch ausnahmsweise gelöscht werden durfte).

Und der Smiley hinter meinem

Zitat:

Und kann heute bzw. morgen, am letzten Tag, noch erstellt werden

sollte darauf hinweisen, dass das nicht wirklich ernsthaft heute oder morgen umzusetzen ist. Also keinesfalls ein

Zitat:

Zitat von himitsu

Und jupp ... schnell schnell, dat schaffst schon noch. (das Wasserfall-Model ... nach mir die Sintflut)

[haentschman]

Moin...:P

Zitat:

Eigentlich sollte es sogar im Livebetrieb möglich sein, einen Trigger zu erstellen

Klar..das bezog sich auf die komplette Umstellung der DB. :wink:

Zitat:

Aber wenn die Software zB zuerst den Master löscht + dann die Details, weil es keine RefIntChecks gibt, geht das so nicht

Zitat:

Nach dem bisherigen Wissensstand scheint mir eine datenbankseitige Abhängigkeit zu fehlen, die sicherstellt, dass kein Master gelöscht werden kann, wenn es noch Details gibt.

So sieht es aus...:roll:

Zitat:

das Wasserfall-Model ... nach mir die Sintflut

...wen trifft die Sintflut? Ich bin der einzige auf der Insel...:zwinker:

:wink:

Nachtrag:
* Trigger erstellt, der eine Exception auslöst und ein Rollback macht. :wink:
* Selbst ich (Admin) könnte keine Addresse löschen, wenn "Vorgänge" zu dieser Addresse vorhanden sind. (über Navigator)
* :shock: Ctrl-Entf geht auch bei DevExpress! ...Umgehung meiner Prüfung! Supiii. :?
* Wenigstens kann ich aus dem CallStack sehen daß ein "KeyDown" stattgefunden hat.

Jetzt heißt es warten...

[TigerLilly]

BTW: Welches Tool erzeugt dir den CallStack?

[DeddyH]

Das sieht nach MadExcept aus.