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

Question

Я получаю ошибку переполнения SqlDateTime (Должно быть между 01.01.1753 12:00:00 и 31.12.9999 11:59:59.) При выполнении INSERT с использованием Linq DataContext, подключенного к SQL Server базы данных, когда я делаю SubmitChanges ().

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

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

Answer 1

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

Answer 2

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

 context.Log = Console.Out;

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

Answer 3

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

Answer 4

Я предлагаю вам изменить Target Framework вашего проекта. Может быть, SQL Server новее, чем .Net Framework. Я вижу ту же вашу проблему:
Целевой каркас моего проекта - 3.5.
SQL Server 2012

А потом я меняю на 4.0. Вопрос решен.

Answer 5

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

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

Мы все ненавидим вводящие в заблуждение ошибки - и это одна из них.

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