Для типа .NET DateTime, почему выводимый тип базы данных SqlDbTypes.DateTime вместо SqlDbTypes.DateTime2? (см. http://msdn.microsoft.com/en-us/library/yy6y35y8.aspx)
Фон
Если по умолчанию используется менее точный тип SQL DateTime, платформа .NET гарантирует, что по умолчанию любое значение .NET DateTime, передаваемое через объект SqlParameter с неопределенным SqlDbType, обязательно будет повреждено . через снижение точности . Это плохое проектное решение, IMO, учитывая, что не будет худших последствий, если просто сохранить полную стоимость.
Например, я не могу использовать метод SqlParameterCollection.AddWithValue, потому что при передаче значения DateTime значение усекается до значения SQL DateTime, которое имеет очень ограниченный диапазон. Результаты либо:
- .NET DateTime значение находится вне допустимого диапазона значения SQL DateTime, и возникает ошибка, или
- Усеченное значение не будет соответствовать более точному значению в базе данных, и оно не будет надлежащим образом совпадать с записями для операций обновления, что еще хуже, IMO, потому что оно тонкое и не генерирует ошибку.
Вопрос
Поскольку .NET DateTime наиболее точно соответствует типу данных SQL Server 2008 «datetime2 (7)» как по точности, так и по диапазону, почему инфраструктура преобразует значение SqlParameter в SQL DateTime и существует ли способ изменить поведение по умолчанию, чтобы я все еще мог использовать функцию вывода типа?
Единственный совет, который я вижу, это то, что функция не работает, и я всегда должен явно указывать тип данных , что потребует много изменений кода. Я предполагаю, что было бы меньше проблем, если бы инфраструктура просто сохранила исходное значение .NET DateTime. Если тип поля базы данных окажется менее точным типом SQL DateTime, то значение строки даты / времени, переданное запросу, будет просто урезано ядром базы данных. Если это выходит за пределы, вы получите ошибку, как и ожидалось. Что еще более важно, если тип поля базы данных - datetime2, тогда все пройдет гладко, и записи будут соответствовать.