Здравствуйте, Koumandin, Вы писали:
K>Привет, люди !
K>А от чего зависит сабж ? K>Я пробовал давать 'YYYY-dd-mm' и 'mm-dd-YYYY' — одинаково хорошо проходит.
K>Зависит ли этот формат от установок сервера и/или баз данных?
очень не рекомендую надеяться на установки локали!!!
всегда приводи строку к дате явно указывая формат(style) используя CONVERT ( datetime, stringexpression, style ), а то, на дай бог, попутаешь месяц с числом, будет неприятно
А как это же можно сделать в Access? Я имею в виду нормально использовать работу с датами в SQL-запросах под Access.
Если можно, несколько примерчиков.
Здравствуйте, DrZubr, Вы писали:
DZ>А как это же можно сделать в Access? Я имею в виду нормально использовать работу с датами в SQL-запросах под Access. DZ>Если можно, несколько примерчиков.
Здравствуйте, Koumandin, Вы писали:
K>Привет, люди !
K>А от чего зависит сабж ? K>Я пробовал давать 'YYYY-dd-mm' и 'mm-dd-YYYY' — одинаково хорошо проходит.
K>Зависит ли этот формат от установок сервера и/или баз данных?
K>Спасибо
Все зависит от того языка, который указан в настройках клиента (Security->Logins->Language), под которым устанавливается соединение. Если для клиента указан русский язык, то сервер будет ожидать, что дата будет в формате dd-mm-yyyy или yyyy-dd-mm, не зависимо от локали сервера или collation базы.
SQL Server Books Online этот счет советуют использовать { ts 'yyyy-mm-dd hh:mm:ss[.fff] '}, что у нас без проблем работает:
Writing International Transact-SQL Statements
Databases and database applications that use Transact-SQL statements will become more portable from one language to another, or will support multiple languages, if these guidelines are followed:
Replace all uses of the char, varchar, and text data types with nchar, nvarchar, and ntext. This eliminates the need to consider code page conversion issues.
When performing month and day-of-week comparisons and operations, use the numeric dateparts rather than the name strings. Different language settings return different names for the months and week days. For example, DATENAME(MONTH,GETDATE()) returns May when the language is set to U.S. English, returns Mai when the language is set to German, and returns mai when the language is set to French. Instead, use a function such as DATEPART that uses the number of the month instead of the name. Use the DATEPART names when building result sets to be displayed to a user because the date names are often more meaningful than a numeric representation; however, do not code any logic that depends on the displayed names being from a specific language.
When specifying dates in comparisons or for input to INSERT or UPDATE statements, use constants that are interpreted the same for all language settings:
ADO, OLE DB, and ODBC applications should use the ODBC timestamp, date, and time escape clauses of:
{ ts 'yyyy-mm-dd hh:mm:ss[.fff] '} such as: { ts '1998-09-24 10:02:20' }
{ d 'yyyy-mm-dd'} such as: { d '1998-09-24' }
{ t 'hh:mm:ss'} such as: { t '10:02:20'}
Applications using other APIs, or Transact-SQL scripts, stored procedures, and triggers, should use the unseparated numeric strings (for example, yyyymmdd as 19980924).
Applications using other APIs, or Transact-SQL scripts stored procedures, and triggers should use the CONVERT statement with an explicit style parameter for all conversions between the date and smalldate data types and character string data types. For example, this statement is interpreted the same for all language or date format connection settings:
SELECT *
FROM Northwind.dbo.Orders
WHERE OrderDate = CONVERT(DATETIME, '7/19/1996', 101)
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Koumandin, Вы писали:
K>>Зависит ли этот формат от установок сервера и/или баз данных?
И от локали подключения больше ... Current Language M>Да, зависит. От установок локали на сервере. M>Но, чтобы с локалью не возиться сервер всегда понимает дату вот в таком формате: M>YYYYMMDD HH:MM:SS M>Подробности здесь:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_qd_14_3unn.asp
M>Все зависит от того языка, который указан в настройках клиента (Security->Logins->Language), под которым устанавливается соединение. Если для клиента указан русский язык, то сервер будет ожидать, что дата будет в формате dd-mm-yyyy или yyyy-dd-mm, не зависимо от локали сервера или collation базы.
M>SQL Server Books Online этот счет советуют использовать { ts 'yyyy-mm-dd hh:mm:ss[.fff] '}, что у нас без проблем работает:
И у меня работает дома, а на работе обломилось. Пришлось ставить 'yyyy-dd-mm'
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Koumandin, Вы писали:
K>>Зависит ли этот формат от установок сервера и/или баз данных? M>Да, зависит. От установок локали на сервере. M>Но, чтобы с локалью не возиться сервер всегда понимает дату вот в таком формате: M>YYYYMMDD HH:MM:SS M>Подробности здесь:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_qd_14_3unn.asp
Здравствуйте, Koumandin, Вы писали:
K>Здравствуйте, magcyril, Вы писали:
M>>Все зависит от того языка, который указан в настройках клиента (Security->Logins->Language), под которым устанавливается соединение. Если для клиента указан русский язык, то сервер будет ожидать, что дата будет в формате dd-mm-yyyy или yyyy-dd-mm, не зависимо от локали сервера или collation базы.
M>>SQL Server Books Online этот счет советуют использовать { ts 'yyyy-mm-dd hh:mm:ss[.fff] '}, что у нас без проблем работает:
K>И у меня работает дома, а на работе обломилось. Пришлось ставить 'yyyy-dd-mm'
Если без указания времени, то надо использовать { d 'yyyy-mm-dd'}
Здравствуйте, magcyril, Вы писали:
M>Если без указания времени, то надо использовать { d 'yyyy-mm-dd'}
Это если через ADO..
А если напрямую в транзакте, то 'YYYYMMDD'
Мы уже победили, просто это еще не так заметно...
ICQ [168117153]
