SQL Server Datetime. Американский против Великобритании?

В моей тестовой БД даты отображаются в формате DD/MM/YYYY. Отображаемый я имею в виду, когда вы щелкните правой кнопкой мыши, откройте таблицу в Management Studio, возвращенные данные будут отображаться в формате DD/MM/YYYY.

Забавно, когда я пишу T-SQL для извлечения записей, мне нужно ввести формат MM/DD/YYYY, чтобы вернуть нужные данные. В любом случае, я могу привести это в формат DD/MM/YYYY?

Ответы

Ответ 1

Вы можете использовать SET LANGUAGE, чтобы выбрать формат даты, который SQL Server ожидает в запросах (я думаю, что студия управления использует региональные настройки клиентского компьютера для отображения, но не уверен, хотя). Однако я предлагаю передавать значения с использованием параметров, а не встраивать их в запрос запроса. При использовании параметров вы не столкнетесь с какими-либо проблемами. Все заботится.

set language us_english
declare @d datetime = '1929/12/18'

set language british
declare @d datetime = '1929/12/18' -- fails

Чтобы изменить язык сервера по умолчанию:

declare @langid int = (select langid from syslanguages where name = 'british')
exec sp_configure 'default language', @langid
reconfigure with override

Ответ 2

Лично я всегда использую формат YYYY-MM-DD (или YYYYMMDD), поскольку он не является специфичным для культуры, и, ну, я думаю, он обращается ко мне, потому что он "логичен" (особенно, когда за ним следует время).

[Edit: я просто говорю о том, что я вставлял в свои SQL-скрипты, чтобы обеспечить совместимость независимо от настроек сервера, а не того, что SQL Server "отображает" ]

Ответ 3

Вы можете установить язык по умолчанию для каждого indvidual входа в SQL Server. Не могу вспомнить, но что-то вроде этого:

sp_defaultlanguage @loginame = 'LoginName', @language = 'Language'

Ответ 4

Если вы передадите DATETIME в формате

dd MMM yyyy

например

"11 JUL 2009"

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

Ответ 5

Практически во всех случаях правильный способ решить эту проблему - просто не рассматривать дату как строку. Если вы передаете параметр или используете значение (типизированного) столбца, то преобразование текста сервера просто не является фактором. В дополнение к тому, чтобы избежать проблемы i18n, это также уменьшает вашу поверхность атаки. И это также экономит несколько циклов процессора; -p

Если вы используете EXEC для динамического SQL, тогда это также должно быть параметризировано с помощью sp_ExecuteSQL.

Ответ 6

Я пытаюсь использовать каноническую форму ODBC даты, где это возможно {d 'yyyy-mm-dd'} Таким образом, я знаю, как это будет интерпретировать сервер sql. Он отлично работает в TSQL.

Ответ 7

Либо добавьте это в свой файл web.config:

</system.web>
    <globalization culture="en-US" uiCulture="en-US" />
</system.web>

или вы можете добавить это выражение на страницу:

<%@ Page uiCulture="en-US" culture="en-US" %>

Надеюсь на эту помощь.