Zitat:
Ich kenne Eure Workflows und Spielregeln nicht.
Zitat:
Ich verstehe nicht, was das mit dem fehlenden Datensatz zu tun hat?
Naheliegend ist bei gegebener Eingabe- und Löschfunktion, dass der Datensatz (versehentlich) gelöscht wurde. Du bestätigst die technische Möglichkeit zum Löschen (und verneinst sie später?). Je nach Backup Zeitpunkt entdeckt man ihn beim Restore wieder oder nicht.
Abhängig von Workflows,
DB Contraints, Privileges, Frontendlogik könnte das eben (durchgängig) verboten sein, das kenne ich nicht.
Ein Server, der definierte
DB Constraints und Rechte nicht einhält, hätte ein ernstes Problem. Das wäre ein schwerwiegendes Problem, weil es genau das aushebelt, was ein
DB Server bietet, garantierte Spielregeln.
Index:
Wenn der Index defekt ist, dann sollte es neu eingespielt funktionieren (Backup) und würde eben genau im Produktivsystem nicht funktionieren. Dies wäre allerdings nur der Fall, wenn zum Aufsuchen des DS eine where Clause verwendet wird, die den Index auch nutzt. Prinzipiell ist ein Index funktional für eine
DB nicht notwendig, er beschleunigt nur. Zur Prüfung dieser Problematik, würde also bereits das gezielte Löschen des fraglichen Index ausreichen. (Abhängig vom Hersteller, Indexart und Nutzung des Index ist diese Pauschalaussage nicht immer haltbar, sie soll das Funktionsprinzip eines Index verdeutlichen, wichtig ist die Unterscheidung zwischen Index an sich und Constraint, dem der Index dient)
Andersrum, eine
Query, die in irgendeiner Form DS abfragt, ohne defekte Indizes zu benutzen, also andere Felder zur Einschränkung nutzt, sollte den DS dennoch anzeigen.
DS neu eingegeben mit gleicher ID:
Das ist normalerweise überhaupt kein Problem, es gibt zwar
DB Typen/Spalten Deklarationen, die einen generierten Schlüsselwert erzwingen, selbst wenn ein anderer Wert rein kommt. Der Normalfall ist aber, dass Trigger Werte oder typgenerierte Schlüsselwerte durch das Insert einfach überschrieben werden, wenn es die Schlüsselspalte enthält.
(Ich weiß nicht, ob
MSSQL solche Spaltenkonstrukte kennt, die generierte ID Werte erzwingen.)
Wenn es also geht, den Datensatz manuell nachzutragen, bedeutet es
a) Der Datensatz war schlicht weg.
b) der PK für die Tabelle ist nicht wasserdicht (vlt. durch mehre Spalten) oder defekt
Man könnte also sicherstellen, dass er nicht doch irgendwo rumfliegt. (Nach Neueingabe nun doppelt):
Die Indizes checken und ggf. neu bauen.
Das System prüfen (
DB und EXE), ob es Lücken in der Rechteverwaltung o.ä. gibt, wegen des Widerspruchs zwischen "Löschen möglich: ja" und "Userrechte dazu vorhanden:nein". Wichtig ist hierbei die Frage, ob die Userrechte auf
DB Ebene realisiert sind (und für welche User) oder woanders. Nur im ersten Fall sollte man sich darauf verlassen können.
Solche Probleme sind eigentlich nur sauber nachvollziehbar, wenn man eine Trigger basierte Bearbeitungshistorie führt (wie bereits von Dir mal angelegt), Probleme fallweise nachvollzieht und die Ursache abstellt.
Dies am besten per File Log, nicht in weitere Tabellen. File Logging funktioniert immer am durchgängigsten (bis Platz fehlt), auch bei
DB Fehlern, Transaktions- Rollback usw.. zielt das Logging wiederum auf Logtabellen, ist es den Gesetzmäßigkeiten der
DB (Transaktionen,..) unterworfen und oft wertlos. (Eine Abschwächung davon wären autonome Transaktionen, sofern vom Hersteller unterstützt)
Nach meiner eigenen Erfahrung sind >99% solcher Probleme keine
DB Fehler, wäre es anders, würde die Nutzung einer
DB kaum Sinn machen, denn die garantierte Funktionalität (ACID) wäre nicht gegeben.
Das gilt so pauschal erst mal für klassische, relationale RDBMS, nicht für noSQL / Dokument
DB.