Блог

Главная - Вопросы по программированию - Тип данных аргумента varchar недопустим для аргумента 1 функции ЧАСОВОГО ПОЯСА AT

Тип данных аргумента varchar недопустим для аргумента 1 функции ЧАСОВОГО ПОЯСА AT

#sql #sql-server #database #type-conversion #sqldatatypes

Вопрос:

Я извлекаю данные из одной таблицы [SourceTable], где тип данных поля, на которое я ссылаюсь (источник), является VARCHAR. [Целевая таблица], в которую я пытаюсь вставить данные, имеет тип данных DATETIME.

При запуске скрипта я получаю следующее сообщение об ошибке:

введите описание изображения здесь

Ниже приведен сценарий, который я запускаю:

 SELECT
    CONVERT(DATETIME, SWITCHOFFSET([BeginDateTime], DATEPART(TZOFFSET, [BeginDateTime] AT TIME ZONE 'US Eastern Standard Time'))) AS [BeginTime]
FROM [SourceTable]

Примечание: У меня есть два экземпляра, где первый-мой «сырой» экземпляр. Отсюда я выполняю моделирование и преобразования, необходимые для структурирования данных.

Комментарии:

1. Послание кажется вполне ясным. Если бы вы предоставили примеры данных, желаемые результаты и объяснение того, что вы хотите реализовать, кто-нибудь мог бы ответить на этот вопрос.

2. …и каков тип данных вашей [BeginDateTime] колонки?

3. Реальный вопрос заключается в том, почему у вас есть столбец, который называется BeginDateTime , когда он не является типом данных даты и времени ? Если это a varchar , то это, по определению, не дата-время.

4. Привет. Извините, я все еще развиваю свои навыки SQL. У меня есть два примера, где первый-мой «сырой» экземпляр. Отсюда я занимаюсь моделированием и преобразованиями.

5. @CaiusJard [начало времени] — это варчар

Ответ №1:

Я успокаиваю себя, потому что изначально поторопился с решением. После просмотра сценария мне удалось решить свою проблему, выполнив следующие действия:

 CONVERT(DATETIME, SWITCHOFFSET(CONVERT(DATETIME, [BeginDateTime], 120) , DATEPART(TZOFFSET, CONVERT(DATETIME, [BeginDateTime], 120) AT TIME ZONE 'US Eastern Standard Time'))) AS [BeginDateTime]

Комментарии:

1. На самом деле это не решение. Правильное решение-использовать правильный тип данных.

2. «Устранение сообщения об ошибке «и» решение фундаментальной проблемы с моделированием данных » — это две совершенно разные вещи

3. @Ник. Макдермейд У меня есть «сырой» экземпляр, в котором я рассматриваю все как один тип данных. Отсюда я выполняю необходимые преобразования и моделирование, чтобы переместить данные в «структурированный» экземпляр. Исходя из контекста, это послужило бы решением моей проблемы 🙂

4. Это разумный подход. Возможно, вы захотите использовать TRY_CONVERT , чтобы вы могли элегантно фиксировать любые проблемы с форматированием

5. Преобразование данных, включающих смещение часового пояса, в тип данных datetime неверно. Вы должны использовать тип данных datetimeoffset, что упростит процесс. Вам вообще не нужно будет конвертировать, просто убедитесь, что строка находится в правильном формате (например: ‘2021-05-18 14:39:05.1790734 -04:00’).

Метки: