Fehlgeschlagenes Update - User informieren

[michael99]

Hallo liebe Leute,

.. ich hätte da bitte eine Frage wie so ein Thema in der "professionellen" Welt angegangen wird.
Also MS SQL DB (C#) mit einer update Anweisung mit mehreren where-Bedingungen. Das Update schlägt fehl (Ergebnis ="0" statt den erwarteten "1") und jetzt möchte ich dem User aber mitteilen warum das update fehlgeschalgen hat. d.h. ich gehe jetzt jede where Bedingung nachher in eigenen Abfragen durch um festzustellen woran es gelegen hat. Aber genau genommen hätten sich ja zwischen fehlgeschlagenem update und einholen der einzelnen where Bedingungen (durch z.B: einen anderen User) die "Verhälnisse" in der DB ändern können. d.h. die zweite Abfragewelle kann das richtige Ergebnis liefern - muß aber nicht.
Also wie macht man das korrekt ?

- danke

Gruß
Michael

[defo]

Ich habe noch nie ein System gesehen oder entwickelt, das soetwas macht.
Einen wichtigen Grund hast Du ja bereits selbst beschrieben.
Neben den nicht (mehr) passenden Where Bedingungen gibt es außerdem eine Reihe anderer Gründe, die das Update verhindern können. (Constraint Verletzung, record locked, ..), die dann auch analysiert und erklärt werden müssten.
Wieso tut es nicht eine einfache, allgemeine Erklärung wie "Datensatz wurde vor dem Speichern bereits geändert"?

[fanderlf]

Ich denke das kommt auch stark darauf für welche Anwendung so etwas konzipiert ist. Wenn die Anwendung recht speziell ist, dann hast Du dort vermutlich auch sehr viel Domänenlogik in der Abfrage. Wenn sich die Benutzer viel mit der Software beschäftigen halte ich es fast für unnötig so etwas zu erklären, weil die Benutzer meistens sofort selbst erkennen was schief gelaufen ist.
Falls das nicht der Fall sein sollte kann man noch eine Art konsistenzprüfung (kleinere Abfragen um den Zustand der DB zu checken) abschicken bevor man ein UPDATE los tritt, um ein konkretere Fehlermeldung zu erhalten.

Generell würde ich so etwas allerdings nie einbauen. Im ersten Schritt würde ich erstmal prüfen ob so ein Szenario überhaupt vorkommt und den Fehler einfach loggen. Siehst Du den Fehler dann öfter im Eventlog kann man Maßnahmen ergreifen

[michael99]

- danke für eure Antworten
ich dachte mir halt es wäre "nett" den Anwender wissen zu lassen wo es happert - weil evtl. kann er ja einfluß nehmen - hat vergessen ein notwendiges Hakerl in einer anderen Tabelle oder so zu setzten. Im Prinzip hab ich es eh so gelöst, daß er dann mitgeteilt bekommt wo noch was fehlt - aber allein die Tatsache das der Verlauf eben nicht 100% wasserdicht ist stört mich ein wenig.
Ich dachte ja schon daran das update in ein Script zu verpacken wo als Antwort eine vom Server generierte Tabelle zurückkommt wo er die Tabellen lockt und die einzelnen Stati ermittelt und dann das update durchführt...

- danke

Michael

[Ralf Jansen]

Um das zu lösen müßtest du vorgehen wie Versionsverwaltungen bei Mergekonflikten.

Du hast die Daten im Zustand A geladen. Während dessen hat die ein anderer User in Zustand B geändert. Jetzt möchtest du A zu C ändern kannst aber A nicht mehr finden. Du brauchst jetzt also eine Gegenüberstellung von A(so habe ich die Daten gelesen),B(so sind sie jetzt in der Datenbank) und C(dahin wollte ich ändern). Denn die Entscheidungen die zur Änderung nach C geführt haben sind jetzt vielleicht ungültig und du müßtest die jetzt eigentlich in den gemergten Zustand D überführen.

Früher bei MIDAS/Datasnap in Delphi (gibts vermutlich heute auch noch hab ich nur seit knapp 'nem Jahrzehnt nicht mehr gemacht) gabs da für einen Reconcilation Process der den User mit einem Dialog zum auflösen der Konflikte konfrontierte. Da man da aber dann eine generische Flache Ansicht der Daten bekam war ein User üblicherweise überfordert und die meisten haben dann doch lieber ein simplen "Daten wurden von anderem Anwender geändert"-Dialog angezeigt und den Vorgang abgebrochen

Beispiel wie das in Delphi aussah http://www.delphisources.ru/pages/fa...fig14_12_0.jpg

[Christian Marquardt]

Wenn der Anwender einen Hakerl vergessen hat, der notwendig ist, ist das eine Frage der Eingabevalidierung und nicht der DB

[michael99]

- danke
also so ein MergeFenster ist für meine Anwendung "zuviel"...

[michael99]

- danke
- da hab ich mich vielleicht nicht optimal ausgedrückt.
Also es gibt z.B. eine Kreuztabelle in der festgelegt werden kann welche ChildModule in welche ParentModule eingebaut werden können (=das Hakerl).
So und jetzt verschiebt der User ein ChildModul von ParentA zu ParentB (=das Update). Das ist aber nicht zulässig - das "Hakerl" für diese Kombination ist nicht gesetzt.
Jetzt bekommt der User mitgeteilt "... verschieben nicht zulässig .. kein gültiges ParentModul..". Der User kann jetzt eben zwischen "..oh - da fehlt ja noch das Hakerl.." oder ".. oh da wollte ich grad einen Unsinn machen ..." wählen. Nur sind es eben einige Bedingungen die da erfüllt sein müssen. Und eben dieses kurze Zeitfenster zwischen fehlgeschlagenem Update und dem Herausfinden und Mitteilen was die Ursache war "stört" mich ein wenig..

Michael

[defo]

Nur sind es eben einige Bedingungen die da erfüllt sein müssen. ..

Nun, diese Bedingungen sind ja offenbar nur am Rande durch Datenbankconstraints definiert, es handelt sich ja eher um bekannte Business Rules.
Der Weg wäre hier wohl eher, dass je Arbeitsschritt diese Regeln geprüft werden und das UI entsprechend dargestellt wird. Also bspw. wird das Verschieben (Drag&Drop?) zum neuen Parent erst ermöglicht, wenn der Parent mittels Haken aktiviert wurde.
Speziell wird das ganze dann uU, wenn die Regeln eine begrenzte Daten-Resource betreffen, auf die User konkurrierend zugreifen (Stichwort, "noch xy Elemente auf Lager").

[michael99]

.. hm - der Ansatz hat was. Das Problem quasi "aktiv" zu umgehen... Ich müßte mir mal überlegen was das bedeutet wenn jedes Modul das "angegriffen" wird für alle anderen Module die ganzen Parameter zu ermittlen hat und dann umzusetzten...

- danke

[defo]

Wir machen sowas teilweise in unseren Projekten. Das Backend liefert dann z.B. enabled/disabled, -ReasonID für bestimmte Ops.
Diese Prüf-Funktionen werden dann innerhalb der OP selbst erneut gerufen, um sicherzustellen, dass sich nichts geändert hat. Ist u.U. aber performance kritisch.