Как отловить ошибку приведения даты в C#?

Question

[Павел]

Есть 2 компьютера: dev и сервер.
На машине разработчика запрос обрабатывается нормально, а на сервере вылетает исключение:

System.Data.SqlClient.SqlException: Преобразование типа данных varchar в тип данных datetime привело к выходу значения за пределы диапазона.

Вот запрос:

SELECT COUNT(*) FROM view_Request 
WHERE ( ( Executor.exist('(/Items/Item[@id="paco"])[1]') = 1) 
AND  ( StatusName = 'в работе' OR StatusName = 'не рассмотрена' OR StatusName = 'обязательно сегодня') 
AND  ( Created >= '2015-10-19' AND Created <= '2015-10-26'))

Что интересно, если выполняю этот запрос в MS SQL Management Studio, все нормально отрабатывает и на dev и на сервере. А вот в коде на 3-й строке вылетает exception:

var da = new SqlDataAdapter(sqlQuery, con);
var dt = new DataTable();
da.Fill(dt);

Куда смотреть, что править? Смотрел конфигурацию IIS - локаль стоит одинаковая. В SQL-сервере тоже настройки идентичны. Что я упустил?

Answer 1

[Зелимхан Бельтоев]

Не пробовали дату в стандартном формате писать? Как бы всегда избавляет от проблем такого рода

Created >= '19.10.2015 0:00:00' AND Created <= '26.10.2015 0:00:00'

UPD:
Для тех, кто в подобной ситуации, но не дошёл до комментариев:

TRY_PARSE('26/10/2015 00:00:00' AS DATETIME USING 'ru-ru')

Comments

[Зелимхан Бельтоев]

И, да: StatusName я бы всё-таки в отдельной таблице хранил

[Павел]

Зелим Бельтоев: почему в отдельной?

[Павел]

Попробовал
SELECT COUNT(*) FROM view_Request WHERE Created >= '19.10.2015 0:00:00' AND Created <= '26.10.2015 0:00:00'

Такой запрос теперь и в MSSQL Man Studio не обрабатывается:
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

[Зелимхан Бельтоев]

Павел: у вас избыточность появляется, когда в StatusName вы так строки храните (кстати, это у вас по первой нормальной форме сейчас).
Логичнее выделить табличку Statuses, в которой хранить ID статуса и Name ('в работе', 'не рассмотрена', 'обязательно сегодня' и др.), а уже в view_Request хранить ID такого вот статуса (кстати, это будет вторая форма нормализации).
Отсюда, например, захотели вы изменить имя статуса с 'обязательно сегодня' на 'СРОЧНО! СРОЧНО! СРОЧНО!': в вашем случае придется апдейтить все записи в view_Request с полем 'обязательно сегодня', когда как можно в одной таблице Statuses поправить одну запись

[Станислав Силин]

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

[Павел]

попробовал такой запрос, как query работает а из программы то же самое исключение

SELECT COUNT(*) FROM view_Request WHERE Created >= '2015-10-19 0:00:00' AND Created <= '2015-10-26 0:00:00'

[Зелимхан Бельтоев]

Павел: пробуйте свою дату через STR_TO_DATE преобразовать ( dev.mysql.com/doc/refman/5.7/en/date-and-time-func... )

[Павел]

Зелим Бельтоев: причем тут MySQL? Я же написал, что в моем случае это MS SQL и там функции STR_TO_DATE нет

[Зелимхан Бельтоев]

Павел: и что, что MySQL? аналоги искать не пробовали? Главное же, что направление дал, а дальше найти, что

TRY_PARSE('26/10/2015 00:00:00' AS DATETIME USING 'ru-ru')

решит вашу проблему, не так уж и сложно выходит. Нет же, всё разжевать нужно

[Павел]

Зелим Бельтоев: конечно аналоги пробовал, вот (но этот вариант тоже выдает ошибку):

SELECT COUNT(*) FROM view_Request
WHERE Created >= convert(datetime, '2015-10-19') AND Created <= convert(datetime, '2015-10-26')

[Павел]

Зелим Бельтоев: вариант с TRY_PARSE помог, спасибо.
Но понятно, что это костыль, а не решение проблемы. Понять бы где нестыковка в локали на вышестоящем уровне.

[Зелимхан Бельтоев]

Павел: вариант с TRY_PARSE, как и с CONVERT (кстати, он бы у вас тоже заработал, если третьим параметром передали код формата даты) - пусть и немного как костыль, но универсальный костыль - вы не зависите от настроек системы и при смене сервера или изменении настроек БД, у вас снова не вылетит исключение или, что еще хуже, будет работать также, но неверно распознавать дату (например, месяц с днём путать) - это отлавливать и отлаживать было бы очень ужасно.

[Павел]

Зелим Бельтоев: пол дня искал решение. Спасибо, что разжевали

[Зелимхан Бельтоев]

Павел: рад был помочь =) Над нормализацией той таблицы всё-таки подумайте

Answer 2

[GavriKos]

Формат даты зависит от региональных настроек конкретной машины.

Comments

[Павел]

где смотреть эти региональные настройки?

[GavriKos]

В панели управления: https://yadi.sk/i/_BfHznkjk6fUj

[Павел]

GavriKos: эти настройки я сравнил в первую очередь - идентичные

[mletov]

Региональные настройки могут так же отличаться в самом MS SQL, посмотрите в MSSQLSMS "Безопасность->Имена входа->Имя юзера->Общие->Язык по умолчанию" на локалке и на внешнем.

Answer 3

[mletov]

И еще в Web.Config просмотрите, добавьте строку что-то типа такой (значение culture выберите сами), у меня такое было, когда на локалке стояла русская винда, на сервере английская. Причем изменение языковых настроек самой машины не помогали, а изменение Web.config сработало.

<globalization uiCulture="ru" culture="ru-RU" />

Answer 4

[heartdevil]

Привет.

Думаю, такое может быть если формат даты неверный.

Comments

[Павел]

если на одноц машине запрос отрабатывает корректно, а на другой этот же запрос не отрабатывает, то дело явно не в формате даты.

Answer 5

[eRKa]

Все дело в формате даты. При ее написании нужно учитывать культуру, где вы ее читать будете.

Answer 6

[Антон Папин]

Ну, кроме того, что вы используете plain sql в коде в XXI веке, вместо того, чтобы использовать одну из замечательных ORM,

вы забыли, что в таких операциях полезно в начало скрипта вставить SET DATEFORMAT

Однако, я всё ещё настойчиво рекомендую использовать ORM. Entity Framework, NHibernate, или любой другой на ваш вкус.