SQL In和Like 参数化

sql 语句进行 like in 参数化,按照正常的方式是无法实现的
我们一般的思维是:

Like 参数:
string strSql = "select * from Person.Address where City like ‘%@add%‘";
SqlParameter[] Parameters=new SqlParameter[1];
Parameters[0] = new SqlParameter("@add", "bre");

In 参数
string strSql = "select * from Person.Address where AddressID in (@add)";
SqlParameter[] Parameters = new SqlParameter[1];
Parameters[0] = new SqlParameter("@add", "343,372,11481,11533,11535,11755,11884,12092,12093,12143");

可是这样放在程序里面是无法执行的,即使不报错,也是搜索不出来结果的,
去网上搜索也没有一个明确的答案,经过反复试验,终于解决这个问题
正确解法如下:

like 参数
string strSql = "select * from Person.Address where City like ‘%‘+ @add + ‘%‘";
SqlParameter[] Parameters=new SqlParameter[1];
Parameters[0] = new SqlParameter("@add", "bre");
 
in 参数
string strSql = "exec(‘select * from Person.Address where AddressID in (‘[email protected]+‘)‘)";
SqlParameter[] Parameters = new SqlParameter[1];
Parameters[0] = new SqlParameter("@add", "343,372,11481,11533,11535,11755,11884,12092,12093,12143");

时间: 2024-10-31 19:36:03

SQL In和Like 参数化的相关文章

SQL Server里简单参数化的痛苦

在今天的文章里,我想谈下对于即席SQL语句(ad-hoc SQL statements),SQL Server使用的简单参数化(Simple Parameterization)的一些特性和副作用.首先,如果你的SQL语句包含这些,简单参数化不会发生: JOIN IN BULK INSERT UNION INTO DISTINCT TOP GROUP BY HAVING COMPUTE Sub Queries 一般来说,如果你处理所谓的安全执行计划(Safe Execution Plan),SQL

Sql语句中使用参数化的Top

在sql中使用参数化的Top,Top后面的参数要用括号括起来. 例如: select top (@ts) ID, [Type], Title, Content, LinkMan, Tel, CheckState, [Date] from tb_Frinfo where [Type] = @type order by [Date] Desc

Sql Server参数化查询之where in和like实现详解

来自:http://www.cnblogs.com/lzrabbit/archive/2012/04/22/2465313.html#wherein 文章导读 拼SQL实现where in查询 使用CHARINDEX或like实现where in 参数化 使用exec动态执行SQl实现where in 参数化 为每一个参数生成一个参数实现where in 参数化 使用临时表实现where in 参数化 like参数化查询 xml和DataTable传参  身为一名小小的程序猿,在日常开发中不可以

参数化查询为什么能够防止SQL注入

很多人都知道SQL注入,也知道SQL参数化查询可以防止SQL注入,可为什么能防止注入却并不是很多人都知道的. 本文主要讲述的是这个问题,也许你在部分文章中看到过这块内容,当然了看看也无妨. 首先:我们要了解SQL收到一个指令后所做的事情: 具体细节可以查看文章:Sql Server 编译.重编译与执行计划重用原理 在这里,我简单的表示为: 收到指令 -> 编译SQL生成执行计划 ->选择执行计划 ->执行执行计划. 具体可能有点不一样,但大致的步骤如上所示. 接着我们来分析为什么拼接SQ

C#参数化执行SQL语句,防止漏洞攻击本文以MySql为例【20151108非查询操作】

为什么要参数化执行SQL语句呢? 一个作用就是可以防止用户注入漏洞. 简单举个列子吧. 比如账号密码登入,如果不用参数, 写的简单点吧,就写从数据库查找到id和pw与用户输入一样的数据吧 sql:select id,pw where id='inputID' and pw='inputPW'; 一般情况没什么问题,但如果用户输入的id或PW带 ‘ ,这是可能就会出现漏洞,bug了 比如用户输入的id是: 1‘ or ’1‘=‘1 这是sql语句执行的是:select id,pw where id

【转载】Sql Server参数化查询之where in和like实现详解

文章导读 拼SQL实现where in查询 使用CHARINDEX或like实现where in 参数化 使用exec动态执行SQl实现where in 参数化 为每一个参数生成一个参数实现where in 参数化 使用临时表实现where in 参数化 like参数化查询 xml和DataTable传参  身为一名小小的程序猿,在日常开发中不可以避免的要和where in和like打交道,在大多数情况下我们传的参数不多简单做下单引号.敏感字符转义之后就直接拼进了SQL,执行查询,搞定.若有一天

为什么要参数化执行SQL语句呢?

C#参数化执行SQL语句,防止漏洞攻击本文以MYSQL为例[20151108非查询操作] 为什么要参数化执行SQL语句呢? 一个作用就是可以防止用户注入漏洞. 简单举个列子吧. 比如账号密码登入,如果不用参数, 写的简单点吧,就写从数据库查找到id和pw与用户输入一样的数据吧 sql:select id,pw where id='inputID' and pw='inputPW'; 一般情况没什么问题,但如果用户输入的id或PW带 ' ,这是可能就会出现漏洞,bug了 比如用户输入的id是: 1

SQL Server SQL性能优化之--数据库在“简单”参数化模式下,自动参数化SQL带来的问题

数据库参数化的模式 数据库的参数化有两种方式,简单(simple)和强制(forced),默认的参数化默认是“简单”,简单模式下,如果每次发过来的SQL,除非完全一样,否则就重编译它(特殊情况会自动参数化,正是本文想说的重点)强制模式就是将adhoc SQL强制参数化,避免每次运行的时候因为参数值的不同而重编译,这里不详细说明. 这首先要感谢“潇湘隐者”大神的提示, 当时也是遇到一个实际问题, 发现执行计划对数据行的预估,怎么都不对,有观察到无论怎么改变参数,SQL语句执行前都没有重编译,疑惑了

参数化查询为什么能够防止SQL注入 (转)

很多人都知道SQL注入,也知道SQL参数化查询可以防止SQL注入,可为什么能防止注入却并不是很多人都知道的. 本文主要讲述的是这个问题,也许你在部分文章中看到过这块内容,当然了看看也无妨. 首先:我们要了解SQL收到一个指令后所做的事情: 具体细节可以查看文章:Sql Server 编译.重编译与执行计划重用原理 在这里,我简单的表示为: 收到指令 -> 编译SQL生成执行计划 ->选择执行计划 ->执行执行计划. 具体可能有点不一样,但大致的步骤如上所示. 接着我们来分析为什么拼接SQ