Сохранение формата при передаче значений DateTime в хранимую процедуру - PullRequest
0 голосов
/ 31 октября 2011

У меня есть серверный элемент управления TextBox в веб-форме, скажем, txtDueDate .Я не хочу использовать DateTimePicker, но хочу использовать сам TextBox.Пользователь вводит дату в формате дд / мм / гггг.

При передаче этого значения в хранимую процедуру SQL Server 2005 (Express) я использую что-то вроде:

cmdParameters.AddWithValue("@DueDate", Convert.ToDateTime(txtDueDate.Text));

Хранимая процедура имеетвходной параметр для обработки этого значения и объявлен как:

@DueDate SmallDateTime

Я хочу знать формат по умолчанию, используемый SQL Server 2005 для внутреннего хранения этой даты.На моем ПК для региональных настроек Windows XP задан формат дд / мм / гггг.При просмотре записей через Management Studio она сохраняется правильно.Но я беспокоюсь о пользователях, которые будут использовать это веб-приложение.Региональные настройки Windows могут различаться на их ПК.

Я хочу быть уверен, что, кто бы ни запрашивал базу данных, дата отображается в формате дд / мм / гггг.Если кто-то вставит, 01.02.2004, то это не должно становиться действительной обратной датой, такой как: 01.02.2004.

Ответы [ 4 ]

5 голосов
/ 31 октября 2011

A DateTime - это DateTime, это DateTime - он не «имеет» какой-либо (ориентированный на строки) формат при хранении в SQL Server (он хранится в виде 64-битной длины).Если вы передаете параметр хранимой процедуре как DateTime, у вас все будет хорошо!Значение будет сохранено SQL Server без изменения какого-либо форматирования - поскольку с ним не связано никакое форматирование ...

Единственная точка, в которой дата является представлена ​​ в заданном строковом формате - это когда вы смотрите на него в SQL Server Management Studio или когда вы конвертируете его в строковый формат, например, в ваше приложение .NET.

Когда вам нужно как-то передать строку-представление в SQL Server (например, для поиска и т. д.), наиболее надежный и будет работать с любым региональным / языковым параметром в формате даты ISO-8601 : YYYYMMDD или в качестве альтернативы (если вам нужна часть времени) YYYY-MM-DDTHH:MM:SS (где T в середине является литералом, разделяющим части даты и времени)

2 голосов
/ 31 октября 2011

DateTime значения не должны храниться в виде текстового формата в базе данных в любом случае - и похоже, что они не.Вы должны просто обработать их как DateTime значения.То, как эти значения форматируются при выходе, зависит от того, что запрашивает базу данных, и вы не можете контролировать это, не просто сохраняя текст, что вы должны , а не . Обрабатывайте значение в его "родном" формате как можно дольше. Старайтесь избегать преобразований в строковые форматы и из них насколько это возможно.

Я бы также не использовал Convert.ToDateTime(text) здесь - насколько вы уверены, что формат системы по умолчанию является правильным для использования здесь?Можете ли вы использовать набор элементов управления, которые дают вам фактическое значение вместо того, чтобы полагаться на то, что пользователь вводит?

0 голосов
/ 31 октября 2011

Преобразование в дату выполняется на стороне клиента:

Convert.ToDateTime(txtDueDate.Text)

По умолчанию используется текущая культура интерфейса пользователя, но вы можете указать культуру со вторым параметром:

Convert.ToDateTime(txtDueDate.Text, new CultureInfo("en-GB"))
0 голосов
/ 31 октября 2011

Вы выбираете ...

1) Если вы обеспокоены тем, что пользователи вводят неправильный формат (неправильный, как в DateTime.Parse выдает исключение), тогда вам нужно проверить ввод

2) Если вы беспокоитесь о том, что пользователи вводят неправильный формат (неправильный, как в DateTime.Parse, вызывает исключение), то используйте средство выбора даты.

...