T-SQL存储过程执行返回-6：临时表数据正常但hComponents未写入数据

• 优先排查空BEGIN CATCH块的异常吞没问题：当前代码的CATCH分支无任何错误捕获与处理逻辑，所有执行过程中触发的异常会被直接静默拦截，既不会向客户端抛出原始报错，也不会主动回滚已开启的事务，是导致执行无明确报错、返回值异常、数据落盘失败的最高概率原因。可以临时在CATCH块中补充错误捕获语句，输出ERROR_MESSAGE()、ERROR_NUMBER()、ERROR_LINE()对应的内容，直接定位真实触发的异常点。
• 排查事务悬挂与隐式事务触发问题：部分数据库实例会开启隐式事务配置（IMPLICIT_TRANSACTIONS为ON），若存储过程前置逻辑已经开启了未提交的事务，后续在TRY块内再执行BEGIN TRANSACTION会导致事务计数叠加，即使代码走到COMMIT也无法真正提交最外层的未提交事务；加上空CATCH块不会执行回滚操作，一旦触发异常就会留下悬挂事务，最终表现为数据完全不落盘。可以在执行存储过程前先查询@@TRANCOUNT的数值，验证事务计数是否符合预期，同时在CATCH块中补充按事务计数层级回滚的逻辑。
• 排查跨schema的权限与所有权链差异：手动分段执行代码时，使用的是个人登录账号的权限校验；但存储过程执行时，若跨schema（当前操作的业务表属于AlteracaoEngenharia schema）的所有权链断裂，会触发存储过程执行权限不足的问题，这类权限报错如果被空CATCH块拦截，就会出现无明确提示、数据写入失败的情况。可以对比异常环境与测试环境的存储过程执行账号权限、schema所有权配置，重点验证执行账号是否对目标schema下的表拥有DELETE、INSERT操作权限。
• 排查写入阶段的约束冲突：当前DELETE语句的清理范围仅覆盖“名称不含(Manual)标识、对应工程变更状态为Aberto”的存量记录，若临时表中待插入的记录存在目标表中未被DELETE覆盖的存量匹配数据（比如存在同主键、同唯一键的手动标识记录、状态非Aberto的存量记录），会直接触发主键冲突、唯一索引冲突、外键关联失败等报错，这类报错会被空CATCH块静默拦截，不会抛出到客户端。可以在INSERT语句执行前，先比对临时表数据与目标表的存量数据，排查是否存在违反表约束的匹配记录。
• 排查数据类型不匹配的隐式转换失败：手动执行查询临时表的语句时，仅会返回表中存储的原始值，不会触发目标表的数据类型校验逻辑；当执行INSERT时，若临时表中字段的数据类型（比如精度、长度、数值格式）和目标表对应列的类型不兼容，会触发隐式转换失败的报错。这类问题在测试环境能跑通，大概率是两个环境的字段类型精度配置不一致（比如测试环境的字段长度更宽松、数值范围更大）。

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