动态拼接列名易出错，需用nvarchar(max)声明@sql、方括号包裹列名、加表前缀、go分隔；参数校验、临时表命名规范、exec后错误处理及bi参数绑定均须严谨。
存储过程里动态拼接列名容易出错
用 CREATE PROC 写报表逻辑时，如果要生成“按日展开”的宽表（比如 dt_clientNo 作为行，1日～31日作为列），必须用字符串拼接 SQL。但 @SQL 变量类型选错、引号嵌套漏掉、空格缺失，都会导致 EXEC(@SQL) 报错或结果为空。
-
@SQL必须声明为VARCHAR(8000)或NVARCHAR(MAX)，VARCHAR(500)肯定不够 - 列别名带空格或数字开头时，必须用方括号包裹，比如
[1]、[31]，写成1会语法错误 - 拼接
UPDATE语句时，DAY(a.[dt_DateTime]) = 1这类条件不能漏掉a.前缀，否则多表执行时报“列名不明确” - 最后一定要加
GO分隔批处理，否则DROP PROC可能被前面的EXEC拦截
参数传入和日期边界处理不严谨
传年月参数进存储过程做月报时，直接用 @YEAR + '-'+ @MONTH + '-01' 拼日期字符串，遇到月份是 1 而不是 01 就会解析失败；更麻烦的是跨年场景（比如12月后是下一年1月），@MONTH+1 算出来是13，CAST('2025-13-01' AS DATE) 直接报错。
- 改用
DATEFROMPARTS(@YEAR, @MONTH, 1)构造起始日，再用EDATE()或DATEADD(MONTH, 1, ...)算月末，安全得多 -
DATEDIFF(day, ..., ...)计算天数前，确保两个日期都是合法DATE类型，别用字符串硬拼 - 对输入参数加校验，比如
IF @MONTH NOT BETWEEN 1 AND 12 RETURN，避免下游逻辑崩掉
临时表命名和清理常被忽略
示例中用 Tmp3 这种裸名建临时表，多人并发调用时会冲突；而且没考虑异常中断后残留，下次执行直接报“对象已存在”。
- 改用本地临时表
#Tmp3（单井号），作用域限于当前会话，自动销毁 - 不要在存储过程末尾写
DROP TABLE Tmp3，因为#Tmp3不需要手动删 - 如果真要用全局临时表（双井号
##Tmp3）或永久表，务必加IF OBJECT_ID('Tmp3', 'U') IS NOT NULL DROP TABLE Tmp3 - 所有
EXEC(@SQL)后建议加IF @@ERROR 0 RAISERROR(...)，方便定位哪条动态 SQL 失败
BI 工具里调用带参存储过程要绑定视图参数列
OurwayBI 这类工具里，把存储过程当数据源添加后，即使数据库端已定义 @YEAR、@MONTH 参数，前端默认也不会暴露出来——你得手动进“视图设置”，找到“参数列”，把对应字段拖进去并映射到存储过程参数名。
- 映射名必须完全一致：存储过程定义是
@YEAR，就不能填year或YR - 参数类型要匹配：
@YEAR INT对应 BI 里选“整数”，别选成“文本” - 测试时先在 BI 的“筛选”面板点“参数列”，看是否出现可编辑输入框；没出现说明绑定失败
- 如果存储过程返回多结果集（比如先查统计再查明细），BI 工具通常只认第一个，其余会被丢弃
EXEC(@SQL) 默认以调用者权限运行，但创建/删表需要 CREATE TABLE 权限，而普通报表用户往往只有 SELECT。这时候要么让 DBA 授予 EXECUTE AS OWNER，要么彻底放弃建临时表，改用 CTE + PIVOT 一次性完成。
