Ошибка обрыва SQL без причины

Question

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

Msg 8152, уровень 16, состояние 2
Строка или двоичные данные будут усечены.

SQL-утверждение:

UPDATE TUP 
SET insured_state_cd = UTCA.state_province_cd 
FROM #TEMP_UAFR_POLICY TUP 
    JOIN dbo.UVW_THIRDS UT ON 
     TUP.prim_owner_third_id = UT.third_id 
    JOIN dbo.UVW_THIRDS_CONTACTS_ADDRESSES UTCA ON 
     UT.primary_address_id = UTCA.address_id 
    JOIN dbo.UVW_INTERNATIONAL_COUNTRY UIC ON 
     UTCA.country_cd = UIC.country_cd 

Теперь, я расскажу вам, что да, в столбце UTCA.state_province_cd больше, чем колонны insured_state_cd. Мы знаем, что это не очень хорошо, но для нашего процесса тестирования потребуется минимум месяц, чтобы получить одобрение изменений и в производство. Нам действительно нужно выяснить причину этой проблемы.

Мы проверили таблицу UTCA, и никакая запись не имеет длину более 2, которая является размером столбца таблицы TUP. Так как это тип CHAR, мы также проверили двоичные значения таблицы, чтобы убедиться, что это не возврат каретки или какой-либо другой скрытый символ.

Чтобы добавить к тайне, этот код работает:

UPDATE TUP 
SET insured_state_cd = UTCA.state_province_cd 
FROM #TEMP_UAFR_POLICY TUP 
    JOIN dbo.UVW_THIRDS UT ON 
     TUP.prim_owner_third_id = UT.third_id 
    JOIN dbo.UVW_THIRDS_CONTACTS_ADDRESSES UTCA ON 
     UT.primary_address_id = UTCA.address_id 
    JOIN dbo.UVW_INTERNATIONAL_COUNTRY UIC ON 
     UTCA.country_cd = UIC.country_cd 
WHERE UTCA.state_province_cd IN 
      (SELECT DISTINCT UTCA2.state_province_cd 
      FROM dbo.UVW_THIRDS_CONTACTS_ADDRESSES UTCA2) 

Как вы можете видеть, второй код такой же, как первый, это в основном только чеками делает 1 = 1? Кроме того, код работает на нашем сервере разработки, как есть, в оригинальной форме. Мы буквально поддерживали db, восстанавливали Dev, запускали код, и он работает.

Answer 1

Мое предположение, что вы использовали LEN (столбец) для проверки данных? Это скажет вам количество символов и не будет содержать пробелов. У меня такое ощущение, что пустое пространство - вот почему это ошибка. Попробуйте обрезать пробел.

UPDATE TUP 
SET insured_state_cd = RTRIM(LTRIM(UTCA.state_province_cd)) 
FROM #TEMP_UAFR_POLICY TUP 
    JOIN dbo.UVW_THIRDS UT ON 
     TUP.prim_owner_third_id = UT.third_id 
    JOIN dbo.UVW_THIRDS_CONTACTS_ADDRESSES UTCA ON 
     UT.primary_address_id = UTCA.address_id 
    JOIN dbo.UVW_INTERNATIONAL_COUNTRY UIC ON 
     UTCA.country_cd = UIC.country_c 

Answer 2

Ничто из вас не говорит о каких-либо красных флагах или имеет (мне) очевидный ответ. Вот некоторые вещи, которые я хотел бы изучить (которые вы, возможно, уже сделали).

Вы говорите тип «CHAR». CHAR, или VARCHAR? Заставляет нас задаваться вопросом о ведущих и/или конечных пробелах. (Какие-либо nvarchars там? Как насчет varchar (max)?) Это поможет увидеть определения таблиц как #TEMP_UAFR_POLICY, так и UVW_THIRDS_CONTACTS_ADDRESSES.

Вы использовали функции LEN() и DATALENGTH() для проверки столбцов, да?

«Резервное копирование на производство и восстановление при разработке» в сочетании с #tempdbs напоминает мне о времени, когда мы установили SQL с кодовой страницей (или что-то еще) разных из всех наших других установок SQL. Базы все работали одинаково, но системные базы данных, особенно tempdb, работали под разными предположениями, что вызвало некоторые довольно тонкие проблемы. Может, что-то там происходит?

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