2013-07-30 2 views
0

Я знаю, что такие вопросы уже здесь, на SO, но мой вопрос немного отличается от уже существующих вопросов.Datetime to varchar error error

Сценарий: база данных имеет столбец ApptDt типа DateTime со значениями в формате «yyyy-mm-dd hh: mm: ss». Я из Индии, и даты проходят в европейском формате «dd-mm-yyyy». Поэтому каждый раз, когда я получаю эту ошибку:

The Conversion of a Varchar Datatype to a datetime results in an out of range value

Образец запроса 1:

Declare @EffectiveDt as varchar(29) 
    Set @EffectiveDt = '27/07/2013' 
    print Convert(DateTime,@EffectiveDt,102) // throws above error 

Пример запроса 2:

Declare @EffectiveDt as varchar(29) 
Set @EffectiveDt = '07/27/2013'  
print Convert(DateTime,@EffectiveDt,104) // throws above error too 

Вопрос:

  1. двух форматов действительны, и преобразования допускаются в T-Sql ; почему возникают такие ошибки?

  2. Есть ли какие-либо общие функции или сценарии для хранения таких преобразований внутри SQL?

+0

'CONVERT' предполагается использовать для преобразования из' datetime' в различные форматы 'char/varchar'. Второй параметр CONVERT должен иметь тип datetime. – cars10m

+0

@ cars10 AFAIK Convert() Преобразует выражение одного типа данных в другое в SQL Server. –

+0

Пожалуйста, не включайте инструкции по голосованию или закрытию в своем вопросе. Каждый, кто может заработал право голоса/закрытия по своему усмотрению. –

ответ

1

Изменить 102 на 104 (немецкий формат)

SELECT Convert(DateTime,@EffectiveDt,104) 

Demo

+0

благодаря вашему решению. Если я прав, Convert (DateTime, @ EffectiveDt, 104) требует @EffectiveDate в немецком формате .. или Этот конвертирует означает, что вам нужно указать тип формата 102 или 103 или 104, и он будет преобразован в формат времени SQL-времени , Convert can not использовать для переключения форматов ... Am I ???? –

+0

@AmitRanjan: Нет универсальной функции автоматического преобразования. Поэтому вы должны хранить 'DateTimes' как' DateTime', и вы должны преобразовать их в 'DateTime', прежде чем они будут переданы в базу данных. –

1

Просто CAST это вместо того, чтобы пытаться CONVERT его в очень специфической культуре:

SELECT CAST(@EffectiveDt AS DATETIME) 
+0

nope, по-прежнему та же ошибка –

+0

Функция 'CAST' переведена в' CONVERT'. Более того, для 'CAST' невозможно определить стиль для преобразования. –

1

Что вы должны быть это NOT с использованием региональных форматов, таких как d/m/y или m/d/y. Если вы используете однозначный строковый формат, такой как yyyymmdd, тогда никогда не будет проблемы, и вам не придется искать всевозможные сумасшедшие обходные пути. Прежде всего форматируйте свои даты в ясном и стандартном порядке.

Просто потому, что вы из Индии не означает, что вам нужно использовать региональные строки для представления дат. Если вы позволяете людям вводить даты в бесплатный текст (это единственный способ объяснить, что вы закончили с 07/27/2013, 27/07/2013 и 27-07-2013), прекратите это делать или подтвердите их вход. Если кто-то входит в 05/06/2013, как вы узнаете, если они означают 6 мая или 5 июня? SQL Server также не может сказать, и нет волшебного пути (например, в Access), чтобы заставить его угадывать, и транспонировать числа, если они недействительны. На самом деле это довольно страшное поведение.