MSSQL: Datensatz nicht sichtbar

[haentschman]

Sorry, diese Spalte ist die ID Spalte der Tabelle. Wegen Vereinfachung weggelassen...
Die Spalten im where sind wichtig.

Geändert.

[TigerLilly]

Hmm. Ich hätte auf unterschiedliche Sortiereinstellungen oder Zeichensätze getippt. Aber das scheint es nicht zu sein.
Ich hatte sowas mal mit einem defekten Index. Aber das wäre in jedem Backup drin.

[dbo].[BELKopf] ist eine Tabelle und kein View?

Du kannst den Datensatz auch gar nicht (mit anderem WHERE) zur Anzeige bringen?
Die Zahl der Datensätze nach dem RESTORE ist überall gleich?
Die spielst die Daten via RESTORE ein?

[Blup]

Der Index wird doch beim Restore neu aufgebaut? Dann sollte das eigentlich nicht das Problem sein.

Vieleicht ein Backup vom Entwicklungsserver(mit dem Datensatz) erstellen und auf dem Anwenderserver zurückspielen.

[haentschman]

Danke für eure Anregungen...

Ich konnte den Datensatz aus dem Backup, mit der gleichen ID , wieder herstellen. *schwitz*

Trotzdem verstehe ich das nicht. Bei uns ist "öfter...2x im Jahr" mal ein Datensatz verlustig. Ich hatte mal für ein halbes Jahr einen Trigger in der Tabelle, der einen Fehler geworfen hätte, wenn ein Datensatz gelöscht worden wäre. Der Trigger hat nie angeschlagen...weil die User keine Löschrechte haben.

Danke...

[Papaschlumpf73]

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen

[TigerLilly]

Zitat von Papaschlumpf73:

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen

Davon habe ich noch nie gehört. Wenn es die Datenbank gibt + überschreiben nicht angewählt ist, bekommst du eine Fehlermeldung + sonst nichts.

[Papaschlumpf73]

Zitat von TigerLilly:

Zitat von Papaschlumpf73:

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen

Davon habe ich noch nie gehört. Wenn es die Datenbank gibt + überschreiben nicht angewählt ist, bekommst du eine Fehlermeldung + sonst nichts.

Dieser Fehler sollte aber nur kommen, du du Datenbank A durch ein Backup von Datenbank B wiederherstellen willst. Wenn du aber Datenbank A mit einem Backup von Datenbank A wiederherstellen willst, kannst du den Haken auch weglassen.

[jobo]

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.

[haentschman]

Hallo...

Zitat:

Du bestätigst die technische Möglichkeit zum Löschen (und verneinst sie später?).

Technisch besteht die Möglichkeit des Löschens, aber der "Knopf" ist über ein Rechtesystem "disabled". Nuch der Admin hat die Rechte.

Zitat:

Ich hatte mal für ein halbes Jahr einen Trigger in der Tabelle, der einen Fehler geworfen hätte

Über den Trigger konnte ich selbst (Admin) keinen DS löschen! Deshalb wieder ausgebaut.

Zitat:

DS neu eingegeben mit gleicher ID:

Mit

Code:

SET IDENTITY_INSERT ON/OFF

konnte ich die originale ID wieder herstellen. Keine Fehler.

Danke für deine Zeit...