SQLDATETIME -Überlauf beim Einfügen, wenn das Datum mit einem LINQ zu SQL DataContext korrekt ist

Question

Ich erhalte einen SQLDATETIME -Überlauffehler (muss zwischen 1.10.1753 00:00:00 und 03.12.9999 11:59:59 PM sein.) Bei einem Einfügen mit einem LINQ -DataContext, der mit der SQL -Server -Datenbank angeschlossen ist, wenn ich bin, Machen Sie die Submitchanges ().

Wenn ich den Debugger verwende, ist der Datumswert korrekt. Auch wenn ich den Code vorübergehend aktualisiere, um den Datumswert auf DateTime zu legen.

Hat jemand eine Arbeit für dieses Verhalten gefunden? Vielleicht gibt es eine Möglichkeit, zu überprüfen, welche SQL der DataContext in die Datenbank einreicht.

Answer 1

Haben Sie das Feld im Designer als autogenerisch eingestellt? Wenn dies nicht das Problem ist, würde ich empfehlen, die Protokollierung der Datenkontextaktionen in der Konsole einzurichten und das tatsächliche SQL zu überprüfen, das generiert wurde, um sicherzustellen, dass diese Spalte einfügt, und verfolgen Sie rückwärts, um das Problem zu finden.

 context.Log = Console.Out;

FWIW, ich habe oft meine Spalten "CreatedTime" und "LastUpDatedTime" im Designer als autogeneriert (und readonly) festgelegt und ihnen eine geeignete Standardeinstellung oder einen DB -Trigger angeben, um den Wert auf Einfügen oder Aktualisierung einzustellen. Wenn Sie es als autogenerisch einrichten, wird es nicht in das Einfügen/Update einbezogen, auch wenn Sie geändert werden. Wenn die Spalte keine Nulle zulässt, müssen Sie ein alternatives Mittel zur Einstellung des Werts liefern, somit die Standardbeschränkung und/oder die Auslöser.

Answer 2

Sind Sie sicher, dass Sie sich die Spalte Right Date ansehen? Ich passierte mir einmal und der Fehler stellte sich heraus, dass er durch eine andere nicht-merkwürdige Datumsspalte verursacht wurde, die vor dem Senden nicht festgelegt wurde.

Answer 3

Ich bin kürzlich auf das gestoßen. Der Fehler kann auch sagen "Etwas verhindert das Speichern!". Denn in meinem Fall war es nicht der DateTime -Wert, der das Problem war.

Ich dachte, ich würde einen Wert für den Hauptschlüssel geben, und was ankam, war "Null". Da es der Schlüssel ist, kann es nicht null sein - und mein Problem war ganz woanders. Durch die Lösung des Nulls verschwand das Problem.

Wir alle hassen irreführende Fehler - und das ist einer von ihnen.

Zuletzt als Vorschlag ... Wenn Sie die Konvertierung von Daten ein Problem finden, dann verwenden Sie überhaupt keine Daten! Die DateTime -Klasse von .NET unterstützt den Wert "Ticks". Es kann auch eine neue DateTime (Ticks) instanziieren; zu. Der einzige Gotcha mit diesem ist, dass die Implementierung von Zecken in JavaScript einen anderen Ausgangspunkt in der Geschichte hat. Möglicherweise möchten Sie also eine Konvertierung zwischen Zecken, wenn Sie jemals versucht haben, Datensätze von C# zu JavaScript zu erhalten.

Answer 4

Ich schlage vor, Sie ändern das Zielrahmen Ihres Projekts. Vielleicht ist SQL Server neuer als .NET Framework. Ich sehe dasselbe Ihr Problem:
Das Zielrahmen meines Projekts beträgt 3,5.
SQL Server ist 2012

Und dann wechsle ich zu 4.0. Das Problem ist gelöst.

Answer 5

Fazit: Beobachten Sie die Reihenfolge Ihrer Aufrufe bei SubMitchanges () und stellen Sie sicher, dass alle Objekte, die "eingereicht" werden, tatsächlich bereit sind, eingereicht zu werden. Dies geschieht mir oft, wenn ich mitten in den Attributen des neuen Linq -Objekts bin (z. z. B. ein neuer "tbladdress" -Erdatensatz), sodass der Code das "tbladdress" erstellt und versucht, diese Aufzeichnung zu speichern, aber diese Submitchanges () versucht dann auch, den unvollendeten "tBlcontact" -Datensatz einzufügen, was möglicherweise möglicherweise ist Es hat noch keinen erforderlichen "Geburtsdatum" -Feldwert festgelegt. Daher scheint die Ausnahme auftreten zu können, wenn ich das Objekt/die TBLADdress "-Ebgut" einfügte, aber tatsächlich auf den Mangel an "Geburtsdatum" für das "TBLContact" -Objekt/die "tbLContact" bezieht.