php - 'login' 中的未知列 'where clause'

Question

是的，我知道，这是常见问题，但过去 3 小时我无法解决。

我做这个查询:

$query = 'UPDATE `'.$masterapp_users_table.'` SET `login` = "'.htmlspecialchars(strip_tags($_POST['login'])).'", `pass` = "'.md5(htmlspecialchars(strip_tags($_POST['pass']))).'", `email` = "'.htmlspecialchars(strip_tags($_POST['email'])).'", `firstname` = "'.htmlspecialchars(strip_tags($_POST['fn'])).'", `secondname` = "'.htmlspecialchars(strip_tags($_POST['sn'])).'" WHERE `login` = "'.htmlspecialchars(strip_tags($_POST['previouslogin'])).'"';
            echo $query.'<br />';
            mysql_query($query) or die(mysql_error());

我明白了:

UPDATE `masterapp_users` SET `login` = "asdasdasd", `pass` = "a3dcb4d229de6fde0db5686dee47145d", `email` = "asdasdasd", `firstname`
= "asdasdasd", `secondname` = "asdasdasd" WHERE `login` = "88888881"<br />Unknown column 'login' in 'where clause'

但它改变了记录!也许有人能看到我看不到的东西？

哦!忘了说:如果我将该字符串从浏览器粘贴到 PMA，它工作正常。

更新:

CREATE TABLE IF NOT EXISTS `masterapp_users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
  `pass` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
  `email` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
  `firstname` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
  `secondname` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `email` (`email`),
  UNIQUE KEY `login` (`login`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=33 ;

Answer 1

该错误表示MasterApp_Users 表中的列未被称为login；它是 Login 或 LOGIN 或 log_in 或 user 或 username 或 用户名 或 ...

在构造字符串的语句中，你有反引号:

 UPDATE `'.$masterapp_users_table.'` SET `login` ...

在 echo 中，那些反引号没有显示。

如果你像那样使用反引号，列名就会区分大小写。 CREATE TABLE 语句的准确拼写是什么？列名是否在反引号内以混合大小写形式书写？

---

...现在我们已经显示了表模式，它不太容易解释(不是以前很容易解释)...

您确定您的浏览器和 PHP 连接到同一个数据库吗？

为了进一步调试，我建议更改:

• 用于指定 id 列和适当值的 WHERE 条件。
• 不要设置 login 列。

检查更新是否改变了您预期的改变。

如果它没有更改您认为应该更改的记录(但它确实有效)，那么您在识别数据库时遇到了问题。

如果您最终找不到不同的列，我们可以非常确定完全不同的表格。也许执行 SELECT * FROM masterapp_users 并查看返回的列定义。

如果它改变了记录，那么我们手上就有了一个深奥的谜团。

---

It changes the record.

投诉专门针对 WHERE 子句中的 login 列。如果在 WHERE 子句中指定 id，是否可以在语句的 SET 子句中设置 login？

如果是这样，这开始看起来像是 DBMS 中的错误。很难理解为什么它会在 WHERE 而不是 SET 中提示 login。因此，它不太可能成为解决方案。

如果消息更改为大致等同于“SET 子句中的未知列 login”，则存在某种自洽性。

如果重命名表中的列并相应地修改代码，会发生什么情况？

---

决议

评论 N:

If it allows SET login = ... and not WHERE login = ... in a single statement, then I think you've got a bug. I'm surprised; it isn't like a DBMS (any DBMS) to be quite that capricious, so I'd need to be very sure about it before calling it a bug. It may also mean there's another factor at play here. If you add an echo "Hi" after the mysql_query() or die line, does that get through? Are you in fact debugging the wrong bit of SQL? Maybe there's a SELECT or something afterwards that's malformed?

评论 N+1:

Yeah thanks! After I add echo 'Hi'; after mysql_query, it appeared, so the problem was in my next queries. I knew that the problem was stupid. facepalm

谁从未犯过类似的错误？