Переполнение SqlDateTime на INSERT, когда дата верна с использованием Linq to SQL DataContext

Question

Я получаю ошибку переполнения SqlDateTime (должно быть между 1/1/1753 12:00:00 AM и 12/31/9999 11:59:59 PM .) при выполнении INSERT с использованием Linq DataContext, связанного с базой данных SQL Server, когда я выполняю функцию SubmitChanges().

Когда я использую отладчик, значение даты верное. Даже если я временно обновляю код, чтобы установить значение даты в DateTime.Now, он не будет делать вставку.

Неужели кто-нибудь нашел обход для этого поведения? Возможно, есть способ проверить, что SQL, который datacontext представляет в базу данных.

Answer 1

У вас есть поле, установленное как автогенерируемое в дизайнере? Если это не проблема, я бы предложил настроить регистрацию действий контекста данных на консоль и проверить фактический SQL-код, чтобы убедиться, что он вставляет этот столбец, а затем трассировать назад, чтобы найти проблему.

context.Log = Console.Out; 

FWIW, я часто устанавливают свои «CreatedTime» и «LastUpdatedTime» столбцы в качестве генерироваться автоматически (и только для чтения) в конструкторе и дать им соответствующее значение по умолчанию или использовать триггер DB, чтобы установить значение при вставке или обновлении , Когда вы настроите его как автогенерируемое, оно не будет включать его в вставку/обновление, даже если оно будет изменено. Если столбец не разрешает нули, то вам нужно предоставить альтернативное средство для установки значения, таким образом, ограничение по умолчанию и/или триггер.

Answer 2

Вы уверены, что ищете подходящую колонку даты? Случилось со мной один раз, и ошибка оказалась вызвана другим столбцом даты, не подлежащим обнулению, который не был установлен перед отправкой.

Answer 3

Я натолкнулся на это недавно. Ошибка может также сказать: «что-то предотвращает спасение!». Потому что в моем случае проблема была не в значении DateTime.

Я думал, что передаю значение для первичного ключа, и то, что прибывало, было «null». Будучи ключом, он не может быть нулевым - и поэтому моя проблема была полностью в другом месте. Решая нуль, проблема исчезла.

Мы все ненавидим обманчивые ошибки - и это один из них.

И наконец, в качестве предложения ... Если вы нашли конверсию дат проблемой, то не используйте даты вообще! Класс DateTime .NET поддерживает значение «Ticks». Он также может создавать новую дату DateTime (тики); слишком. Единственный Gotcha с этим, это реализация тиков в Javascript, имеет другую отправную точку в истории. Поэтому вам может потребоваться преобразование между тиками, если вы когда-либо пробовали получать DateTimes из C# в Javascript.

Answer 4

Предлагаю изменить целевую структуру проекта. Возможно, SQL Server новее, чем .NET Framework. Я вижу то же самое в вашей проблеме:
Целевая структура моего проекта - 3.5.
SQL Server 2012 2012

И затем я перехожу к 4.0. Проблема решена.

Answer 5

Нижняя линия: следите за порядком ваших вызовов в SubmitChanges() и убедитесь, что все объекты, которые будут отправлены, действительно готовы к отправке. Это часто случается со мной, когда я устанавливаю атрибуты нового объекта LINQ (например, «.FirstName» нового «tblContact»), а затем для некоторой условной логики требуется создание отдельной связанной записи (например, новая запись «tblAddress»), поэтому код запускается для создания «tblAddress» и пытается выполнить SubmitChanges() при сохранении этой записи, но этот метод SubmitChanges() также пытается вставить незавершенную запись «tblContact», которая, возможно, 't еще есть необходимое значение поля BirthDate. Таким образом, исключение возникает, когда я вставляю объект/запись «tblAddress», но на самом деле ссылается на отсутствие «BirthDate» для объекта/записи «tblContact».