TRY_CONVERT возвращает NULL для значения, которое выглядит как дата - PullRequest
0 голосов
/ 17 марта 2019

Я получил пользу от функции TRY_CONVERT благодаря ответу на мой последний вопрос .

Теперь я сталкиваюсь со значением в таблице ключ / значение (столбец значений типа NVARCHAR(50)), которое невозможно преобразовать в DATE, даже если оно очень похоже на дату.

enter image description here

Я бы хотел узнать, почему TRY_CONVERT(DATE, [Claim issue complete]) должен возвращать NULL.

Несмотря на то, что я использую подстроку такого значения, результат такой же

SELECT SUBSTRING([Claim issue complete], 1, 10) AS CompletionDate

ОБНОВЛЕНИЕ : текстовая копия изображения

Claim issue complete
2018-09-21 00:00:00+02
2017-10-12 00:00:00+02
2018-01-30 00:00:00+01
2017-07-19 00:00:00+02
2019-02-14 00:00:00+01
NULL
2017-08-06 00:00:00+02
2017-10-04 00:00:00+02
2018-05-18 00:00:00+02
2018-09-05 00:00:00+02
2019-01-14 00:00:00+01
2019-01-24 00:00:00+01
2018-03-21 00:00:00+01
2017-11-28 00:00:00+01
2018-02-26 00:00:00+01
2018-04-05 00:00:00+02
2018-04-27 00:00:00+02

Обновление 2 : пример

Вот пример проблемы.

SELECT TRY_CONVERT(DATE, '2018-09-21 00:00:00+02')

Вышеуказанное возвращает NULL.

Ответы [ 3 ]

1 голос
/ 17 марта 2019

В идеале вам следует изменить структуру базы данных и сохранить ваши значения в соответствующем типе данных - если вам нужно значение даты, сохраните его как Date, если вам нужно со временем, сохраните его как DateTime2 ( Почему бы не DateTime? ) и, если вам нужно, чтобы он был осведомлен о часовом поясе, сохраните его как DateTimeOffset.
Подробнееинформацию, прочитайте Плохие привычки Аарона Бертранда: выбор неверного типа данных .

Формат представления строки, который вы используете в своей базе данных, не соответствует ни одной из встроенных дат временные стили в SQL Server - вот почему Try_Convert терпит неудачу (как, впрочем, и Try_Cast).
Если вас интересует только часть значения даты, вы можете использовать try_castв 10 крайних левых символах - поскольку вы преобразуете в Date, а не DateTime, формат гггг-мм-дд однозначен и всегда будет правильно преобразован:

SELECT  TRY_CAST(LEFT('2018-09-21 00:00:00+02', 10) As DATE)

Если вы хотитевместо этого используйте Try_convert, вам нужно указать параметр style - 120 в этом case:

SELECT  TRY_CONVERT(DATE, LEFT('2018-09-21 00:00:00+02', 10), 120)

Обратите внимание, что вам не нужен код для обработки null входов - они просто будут иметь вид null

0 голосов
/ 18 марта 2019

Добрый день,

SELECT TRY_CONVERT(DATETIME2 , '2018-09-21 00:00:00 +02', 20) -- null, since this '+02' is not a legit OFFSET
SELECT TRY_CONVERT(DATETIME2 , '2018-09-21 00:00:00 +02:00', 20) -- OK
--Solution for bad OFFSET style can be to add the missing string:
SELECT TRY_CONVERT(DATETIME2 , '2018-09-21 00:00:00 +02' + ':00', 20) -- OK

--Same using Date:
SELECT TRY_CONVERT(DATE , '2018-09-21 00:00:00 +02' + ':00', 20) -- OK
0 голосов
/ 17 марта 2019

Причина, по которой SELECT TRY_CONVERT(DATE, '2018-09-21 00:00:00+02') не работает, заключается в том, что это недопустимый формат даты.Если быть точным, то это часть +02 в конце.
Вы можете переписать это так, если знаете, что первые 19 позиций всегда будут YYYY-MM-DD hh:mm:ss:

SELECT TRY_CONVERT(DATE, LEFT('2018-09-21 00:00:00+02', 19))

IВы только что добавили LEFT -функцию для сортировки +02 в конце

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...