Mysqli 准备语句 +约束令 BY
我在使用 mysqli_stmt 准备函数时遇到一个小问题。这是我的查询:
$params = array(
"sisi",
"some_string",
5000,
"date_added DESC"
);
$sql = "SELECT *
FROM scenes
WHERE scene_title LIKE ?
AND scene_id > ?
ORDER BY ?
LIMIT ?";
现在,当我像这样将参数绑定到数组时(我实例化了一个有效的 mysqli_stmt 对象):
call_user_func_array(array($this->mysql_stmt, 'bind_param'), $params);
订单依据未绑定。我在 php.net 上阅读(https://www.php.net/manual /en/mysqli.prepare.php)
标记仅在某些情况下才是合法的 SQL 语句中的位置。例如, 它们允许出现在 VALUES() 列表中 INSERT 语句的(指定 行的列值),或在 与 WHERE 中的列进行比较 子句指定比较值。
但是,它们不允许 标识符(例如表或列 名称),在选择列表中命名 SELECT 返回的列 语句,或指定两个操作数 二元运算符,例如 = 等号。
有没有办法解决这个问题,或者我是否必须使用 mysql_real_escape_char() 作为 ORDER BY 子句?
I am having a small issue with the mysqli_stmt prepare function. Here is my query:
$params = array(
"sisi",
"some_string",
5000,
"date_added DESC"
);
$sql = "SELECT *
FROM scenes
WHERE scene_title LIKE ?
AND scene_id > ?
ORDER BY ?
LIMIT ?";
Now when i bind the params to the array like this (i have a valid mysqli_stmt object instantiated):
call_user_func_array(array($this->mysql_stmt, 'bind_param'), $params);
The order by is not binded. I read on php.net (https://www.php.net/manual/en/mysqli.prepare.php)
The markers are legal only in certain
places in SQL statements. For example,
they are allowed in the VALUES() list
of an INSERT statement (to specify
column values for a row), or in a
comparison with a column in a WHERE
clause to specify a comparison value.However, they are not allowed for
identifiers (such as table or column
names), in the select list that names
the columns to be returned by a SELECT
statement, or to specify both operands
of a binary operator such as the =
equal sign.
Is there a way around this or am i going to have to use mysql_real_escape_char() for the ORDER BY clause?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
正如您找到的 php.net 链接所述,您不能使用绑定变量作为标识符。你需要一个解决方法。
mysql_real_escape_char
肯定是一种方法。As the php.net link you found states, you cannot use bind variables for identifiers. You'll need a workaround.
mysql_real_escape_char
would certainly be one way.