Wir haben seit einiger Zeit Probleme mit Daten in unserer SQL-Datenbank gespeichert.
Manchmal werden Datensätze mit Daten gespeichert, die nicht mit dem Rest der Zeile übereinstimmen, sodass es so aussieht, als würden Daten für etwas anderes, vielleicht für die Daten eines anderen Benutzers, ausgetauscht, bevor sie an die Datenbank übergeben werden.
Wir verwenden TransactionScopes durchgehend mit der Isolationsstufe von ReadCommitted , was mich glauben macht, dass das Problem der Datenintegrität eher in der Anwendung als auf der Datenbankebene liegt.
Wir verwenden die Sitzung ausgiebig und wir beginnen zu denken, dass die Zeiten der korrupten Daten den Zeiten ähnlich sind, in denen wir im Laufe des Tages Updates für das System bereitstellen.
Wir verwenden den Dienst aspnet_state, um die Sitzung über Neustarts von Anwendungen hinweg zu erhalten.
Unsere Benutzer verlassen sich auf Terminalsitzungen, daher loggen sich mehrere Benutzer auf demselben Server ein und starten das System über einen Browser.
Wir haben in der Vergangenheit festgestellt, dass sich Benutzer mit den gleichen Anmeldeinformationen anmelden, aber wir sind jetzt relativ zuversichtlich, dass sich Benutzer jetzt mit eindeutigen Konten anmelden.
99,9% der Daten sind korrekt, aber wir haben uns bemüht zu verstehen, was dieses intermittierende Datenintegritätsproblem verursachen könnte.
Wir beschränken jetzt unsere Deploys auf die äußersten Arbeitszeiten bei Todesfolge, aber das ist nicht immer möglich.
Kann jemand herausfinden, warum / wie dies geschehen könnte?
BEARBEITEN : Wir haben das jetzt auf die DAL-Ebene isoliert, siehe SQL-Abfrage gibt falschen Wert in Multi-User-Umgebung zurück
Ich habe kürzlich gekämpft !, und hatte ein ähnliches Problem wie bei Ihnen, dass etwa 95% der zurückgeschriebenen Daten korrekt waren. Ich habe mir verschiedene Gründe angeschaut, warum der Hauptgrund dafür war, dass einige Nutzer im Netzwerk Chrome heruntergeladen und den Datensatz in Chrome geöffnet hatten, wodurch unsere Sitzungs-ID gebrochen wurde, da Chrome Sitzungen ignoriert.
Die andere Ursache war entweder, dass die Benutzer den Browser nicht schlossen oder die Anwendung nicht abmelden, sodass entweder derselbe Benutzer oder ein völlig anderer Benutzer die Sitzungs-ID auswählen und verwenden konnte.
Nach der Einführung eines Browser-Checks und der Ablehnung von Chrome, der Schulung der Benutzer, um sicherzustellen, dass sie sich abmelden, und der Durchführung von Updates für Zeiten, in denen viel los ist, war das Problem fast vorbei.
Ich habe vergessen, zu erwähnen, dass es auch in Ihrem IIS am besten ist, das Caching im Output Caching zu deaktivieren, damit der Benutzer und das Kernel-Set Caching verhindern.