在存储过程中拼接SQL语句是不是不太好？
我常常在网络上看到很多存储过程的例子里面基本都是拼接一个或多个SQL然后用EXEC运行
例如：
.....
@strsql= 'update   table_name   set   a= ' ' '+   @a   + ' ' '   where   id= '+@id
exec   (@strsql)
==================================================================
而不是直接：
......
update   table_name   set   a=@a   where   id=@id

======================================================================
对于在存储过程中拼接SQL我认为：
1。很容易存在注入漏洞
2。存储过程是预编译的，在存储过程中拼接SQL就意味着SQL语句在运行的时候才生成，也就是说在运行的时候才对其解释执行，这样的活预编译就好象没有意义了
3。能够不拼接就不拼接

以上的观点对不对呢？

也存在这样的问题：如果不使用拼接SQL有些时候会加大存储过程的复杂度或者需要增加参数，两者之间应该如何取舍呢？

除了能简化程序以外，在存储过程中拼接SQL还有什么好处吗？


------解决方案--------------------
个人感觉是一样的...
------解决方案--------------------
我也觉得一样,只不过拼接让人看起来更加方便一些

长长一条难看清楚的
------解决方案--------------------
个人感觉是一样的...
------解决方案--------------------
对这个没有研究。
希望能看到权威的说法。
------解决方案--------------------
担心比较没有必要~~~~
------解决方案--------------------
to 楼主

一开始我以为 用了存储过程 被注入 是因为用 sp_executesql 执行拼合语句引起。

后来详细测试，一般的存储过程都可以被注入(测试环境：Microsoft SQL Server 2005 - 9.00.3042.00 SP2 + B/S&ADO）
------解决方案--------------------
测试的存储过程全部是 ADO Connection.Execute( "存储过程 ")

不知道用了Command会怎样
------解决方案--------------------
想不被注入,那就需要:

1.把sql 示例数据库删除.
2.把用不到的系统存储过程删除.
3.使用最小特权帐号登录数据库,尽量不要用sa帐号,并设sa帐号强密码,并定期修改密码.sa帐号只在万一需要管理数据库时,使用企业管理器才用.但不要用到程序中.
4.删除不用的多余的odbc驱动程序.只保留你常用到的.
5.转义,过滤危险字符 ' --等.拒绝sql 攻击签名: drop, delete, insert, update
6.尽量使用command.
7.select id, name from 表. 尽量不要使用select * from 表这样的形式.
8.对参数进行异常捕捉.
.......

太多了.^______________^