Teradata存储过程报2620错误：字符串拼接操作异常

这个问题我碰到过好几次，核心原因是Teradata的存储过程执行环境和普通SELECT查询的类型转换规则、数据校验逻辑不一样——哪怕你在交互式查询里用||拼接完全没问题，到存储过程里因为变量的类型或数据本身的问题，就会触发2620这个"坏字符"错误。

可能的原因及对应解决办法： #

1. 变量是数值类型，隐式转换失败

如果Hour_of_Day、Minute_of_Hour、Second_of_Minute是INT/DECIMAL这类数值型变量，存储过程里的隐式字符串转换规则比普通SELECT更严格，很容易因为转换过程中的隐形问题触发错误。

解决办法：显式转换为字符串
用TO_CHAR或CAST把数值变量转成字符串，甚至可以指定格式补前导零，让时间格式更规范：

SET Time_of_Day = TO_CHAR(Hour_of_Day, 'FM00') || ' : ' || 
                  TO_CHAR(Minute_of_Hour, 'FM00') || ' : ' || 
                  TO_CHAR(Second_of_Minute, 'FM00');

FM00格式会让单个数字（比如小时是5）转换成'05'，同时去掉多余的空格，避免拼接后出现奇怪的空白字符。

2. 目标变量Time_of_Day长度不足

如果Time_of_Day定义的VARCHAR长度太短，拼接后的字符串超过长度限制，也会触发类似的格式错误。比如拼接后的时间字符串是'09 : 30 : 45'，长度是12，所以要确保Time_of_Day定义为VARCHAR(12)或更长。

解决办法：检查并调整变量长度
修改存储过程里的变量定义：

DECLARE Time_of_Day VARCHAR(12); -- 或者根据实际需要设置更长的长度

3. 变量包含不可见的控制字符/无效字符

即使去掉了TRIM，变量里可能存在诸如换行符、制表符或者其他非打印的控制字符，这些字符会被Teradata判定为"坏字符"。

解决办法：过滤无效字符
用REGEXP_REPLACE清理掉非数字的无效字符，再进行拼接：

SET Time_of_Day = TRIM(REGEXP_REPLACE(Hour_of_Day, '[^0-9]', '')) || ' : ' || 
                  TRIM(REGEXP_REPLACE(Minute_of_Hour, '[^0-9]', '')) || ' : ' || 
                  TRIM(REGEXP_REPLACE(Second_of_Minute, '[^0-9]', ''));

这个语句会把变量里所有非数字的字符替换为空，确保拼接的都是合法的数字字符串。

验证思路 #

你可以先单独把变量的值查出来，看看是否有异常：

SELECT Hour_of_Day, Minute_of_Hour, Second_of_Minute FROM your_table; -- 如果是表变量的话
-- 或者在存储过程里加调试语句，输出变量值
CALL DBMS_OUTPUT.PUT_LINE('Hour: ' || Hour_of_Day);

这样能快速定位是类型问题还是数据本身有坏字符。

内容的提问来源于stack exchange，提问作者KeenLearner