|
AW: MSSQL: Datensatz nicht sichtbar
:oops: Sorry, diese Spalte ist die ID Spalte der Tabelle. Wegen Vereinfachung weggelassen...:oops:
Die Spalten im where sind wichtig. Geändert. |
AW: MSSQL: Datensatz nicht sichtbar
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? |
AW: MSSQL: Datensatz nicht sichtbar
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. |
AW: MSSQL: Datensatz nicht sichtbar
Danke für eure Anregungen...:thumb:
Ich konnte den Datensatz aus dem Backup, mit der gleichen ID :shock:, wieder herstellen. *schwitz* Trotzdem verstehe ich das nicht. :roll: 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. :roll: Danke... |
AW: MSSQL: Datensatz nicht sichtbar
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 :-)
|
AW: MSSQL: Datensatz nicht sichtbar
Zitat:
|
AW: MSSQL: Datensatz nicht sichtbar
Zitat:
|
AW: MSSQL: Datensatz nicht sichtbar
Zitat:
Zitat:
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. |
AW: MSSQL: Datensatz nicht sichtbar
Hallo...8-)
Zitat:
Zitat:
Zitat:
Code:
konnte ich die originale ID wieder herstellen. Keine Fehler.
SET IDENTITY_INSERT ON/OFF
Danke für deine Zeit...:P |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 21:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz