Для типа .NET DateTime, почему выведенный тип базы данных SqlDbTypes.DateTime вместо SqlDbTypes.DateTime2? (См. http://msdn.microsoft.com/en-us/library/yy6y35y8.aspx)
Фон
По умолчанию для менее точного типа SQL DateTime платформа .NET гарантирует, что по умолчанию любое значение .NET DateTime, которое вы передаете через объект SqlParameter с неопределенным SqlDbType, обязательно будет повреждено с помощью сокращения в точности. Это плохое дизайнерское решение, ИМО, учитывая отсутствие худших последствий, просто сохраняя полную ценность.
Например, я не могу использовать метод 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, тогда все будет плавно и записи будут соответствовать правильно.