MSSQL: Datensatz fehlt

[haentschman]

Hallöle...8-)

Ich kann es mir nicht erklären. :?

Bei unseren Adressen (=Kunde) fehlt ab und zu (2 Mal im halben Jahr) ein kompletter Datensatz. :twisted:

Gegeben:
1. Dataset basiert (FDQuery)
2. Kein Nutzer kann löschen (Navigator immer ausgegraut)
3. Nur der Admin kann über seine Rechte löschen
4. ALLE Detaildaten zum Master sind da.
5. Da wo der Datensatz stand ist eine Lücke in der ID

Ich kann es nicht reproduzieren...:roll:

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

Andere Ideen zur Usache?

:wink:

[Jasocul]

Ist die Erfassung über ein Transaction gesteuert?
Falls nicht, könnte ein Programmabsturz die Ursache sein:
Master-Datensatz wurde erfasst, aber noch nicht gespeichert (kein Post). Dann die Detail-Datensätze, die auch gespeichert wurden (Post). Anschließend ein Programmabsturz. Ohne Transaction würde hier auch ein Abbruch der Erfassung zu deinem Phänomen führen.

Ein Log würde ich nicht unbedingt ins Programm einbauen. Mein Weg wäre da eher ein Trigger auf der Datenbank. Besser zwei Trigger. Einen für die Master-Tabelle und einer für die Detais. Die Trigger sollten beim Erfassen und beim Löschen feuern.

Eine andere Idee habe ich noch:
Falls die Master-Daten in einem DBGrid o.ä. angezeigt werden, kann man Datensätze auch mit Strg-Entf löschen, wenn das nicht auf Read-Only steht oder anderweitig abgefangen wird.

Du kannst natürlich auch am Datenbankmodell etwas machen, um dieses Problem in den Griff zu bekommen. Wenn du mit referentieller Integrität arbeitest, sollte die Datenbank das Löschen des Master-Datenatzes verhindern, falls Detail-Datensätze noch existieren.

[haentschman]

Danke...:P

Zitat:

Master-Datensatz wurde erfasst, aber noch nicht gespeichert (kein Post)

Nein. Der Datensatz war da und gespeichert. (aus 07/2020) Durch einen Zufall ist herausgekommen daß der Masterdatensatz fehlt.

Zitat:

Falls die Master-Daten in einem DBGrid o.ä. angezeigt werden, kann man Datensätze auch mit Strg-Entf löschen, wenn das nicht auf Read-Only steht oder anderweitig abgefangen wird.

:shock: ..muß ich prüfen. (DevExpress Grid)

Zitat:

Wenn du mit referentieller Integrität arbeitest

... hätte ich gern. :cry: Klick Bunti Database, Normalisierung = -1...bei einer Anwendung die 356/24 läuft. :roll:

Nächstes Jahr stelle ich die Datasets, auch dieses, auf Objekte um. Damit sind alle Daten in einer Transaktion gekapselt. Dann hoffe ich, daß das aufhört. :wink:

[hoika]

Hallo,
der Detail-Datensazu und der Master fehlt?
Das kann gar nicht sein, wenn mit Foreign Keys gearbeitet wurde.

[DeddyH]

Falsch formuliert: das könnte nicht sein, wenn mit Referentieller Integrität gearbeitet würde.

[haentschman]

Zitat:

der Detail-Datensazu und der Master fehlt?

nein...nur der Master.

[TigerLilly]

Hmm. Den MSSQL Server als Übeltäter kannst du ausschließen. Der löscht keine Sätze ungefragt. Ich würde auch einen kaputten Index ausschließen, der den Datensatz einfach nicht anzeigt.

- Der Datensatz ist in einem Backup auffindbar?
- Kann das dadurch entstehen, dass zwei Benutzer dasselbe zum gleichen Zeitpunkt tun?
- Referentielle Integrität einzubauen dauert ein paar Sekunden + geht am Live-System (wenn die App da nicht in die Quere kommt weil zb Detailsätze NACH dem Master gelöscht werden).
- Wenn Löschen des Masters VOR den Detailsätzen nicht die Regel ist, würde ich einen Trigger aufsetzen, der das Löschen abbricht + damit ich weiß wann und wo das auftritt.

HTH

[haentschman]

Zitat:

Der Datensatz ist in einem Backup auffindbar?

Der Datensatz ist wiederherstellbar gewesen...aber blöd ist das doch. :? Erst Recht wenn es eigentlich nicht möglich ist.

Zitat:

würde ich einen Trigger aufsetzen, der das Löschen abbricht + damit ich weiß wann und wo das auftritt.

...mache ich auch.

:zwinker:

[himitsu]

Ja, da muß man bissl aufpassen, wo überall die Editing und ReadOnly stehen und wo man alles die Daten bearbeiten kann.
Query/DataSet, Grid, DataSet-Field, Grid-Column (Edit), DBNavigator (Einzeln und/oder der im DxGrid)

Und die ShortCuts Einfg/Entf (auch ohne Strg) werden hier oft beim Schreibschutz gern vergessen (in den GridView-Optionen),
weil man sie nicht direkt sieht, im Gegensatz zum Style des Edits oder ob Buttons/Menüs disabled sind und ob das Kontextmenü aufgeht (falls man dort was zum Bearbeiten drin hat).


Passt MSSQL bei den "Referenzen" denn nicht auf?
(Master löschen, obwohl noch ein Detail dran hängt)

[haentschman]

Zitat:

Master löschen, obwohl noch ein Detail dran hängt

Wenn die Datenbank das wüßte, daß das Detaildaten sind, ja. Meine Daten (Tabellen) existieren nebeneinander...nur der Client weiß was zusammen gehört! :evil:
Aktuell könnte man an einem Arbeitsplatz die Positionen eines Auftrages ändern, an einem anderem Arbeitsplatz in dem Auftrag die Adresse ändern. Jeder speichert seine Änderungen...gruselig! :evil:

Eigentlich kein Zustand. Ich bräuchte ein halbes Jahr die Datenbank aufzudröseln...alles im Live Betrieb. :cry:

[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.

[Jasocul]

Zitat:

Zitat von haentschman (Beitrag 1479425)

Moin...:P
* :shock: Ctrl-Entf geht auch bei DevExpress! ...Umgehung meiner Prüfung! Supiii. :?

Jetzt heißt es warten...

Worauf willst du warten?
Ich fange das in meinen Programmen im BeforeDelete ab.
Einfach ein Cancel des Löschvorgangs und für den Anwender eine Exception, dass das unzulässig ist. Wie "nett" du diese formulierst, ist dir überlassen. :twisted:

[haentschman]

Zitat:

Worauf willst du warten?

Ob das mit den Sicherheitsnadeln (Rechte, Trigger, BeforeDelete) immer noch auftritt...wenigstens habe ich dann den CallStack.

PS: Im BeforeDelete gab es auch eine "Willst du löschen?" Abfrage.

[lxo]

Zitat:

* :shock: Ctrl-Entf geht auch bei DevExpress! ...Umgehung meiner Prüfung! Supiii. :?

Das kann man deaktiveren
<TcxGridTableView>.OptionsData.Deleting
oder
<TcxGridTableView>.OptionsData.DeletingConfirmation