2

ええ、私は知っています、その一般的な問題ですが、私は過去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 ;
4

2 に答える 2

5

エラーは、MasterApp_Usersテーブルの列が呼び出されていないことを意味しloginます。それはLoginまたはLOGINまたはlog_inまたはまたはuserまたはusernameまたはuser_nameまたは..。

文字列を構成するステートメントには、バックティックがあります。

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

ではecho、これらのバックティックは表示されていません。

このようなバックティックを使用すると、列名で大文字と小文字が区別されます。CREATE TABLEステートメントのスペルは正確には何でしたか?列名はバックティック内に大文字と小文字が混在して書かれていましたか?


...これでテーブルスキーマが表示されましたが、説明がわかりにくくなっています(前に簡単に説明したわけではありません)...

ブラウザとPHPが同じデータベースに接続していることを確認しますか?

さらにデバッグするには、以下を変更することをお勧めします。

  • id列と適切な値を指定するためのWHERE基準。
  • login列を設定しないでください。

UPDATEが期待する内容を変更するかどうかを確認します。

必要と思われるレコードが変更されない場合(ただし、機能する場合)、データベースの識別に問題があります。

別の列が見つからない場合は、まったく別のテーブルがあることを確信できます。たぶん、を実行して、SELECT * FROM masterapp_users返された列定義を確認してください。

それが記録を変えるならば、私たちは私たちの手に深い謎を持っています。


レコードを変更します。

苦情は特にloginWHERE句の列に関するものでした。idWHERE句で指定した場合login、ステートメントのSET句で設定できますか?

もしそうなら、これはDBMSのバグのように見え始めています。loginSETではなくWHEREで文句を言う理由を理解するのは困難です。したがって、それが解決策になる可能性は低いです。

メッセージが「SET句の不明な列」とほぼ同等のメッセージに変わる場合は、loginある程度の自己整合性があります。

テーブルの列の名前を変更し、それに応じてコードを変更するとどうなりますか?


解像度

コメントN:

それが許可され、単一のステートメントではSET login = ...ないWHERE login = ...場合は、バグがあると思います。びっくりしました。DBMS(任意のDBMS)がそれほど気まぐれであるとは限らないので、バグと呼ぶ前にそれについて非常に確信する必要があります。また、ここで別の要因が働いていることを意味する場合もあります。echo "Hi"行の後にアフターを追加すると、mysql_query() or dieそれは通り抜けますか?実際、SQLの間違ったビットをデバッグしていますか?たぶん、SELECTか、その後に不正な形式の何かがありますか?

コメントN+1:

そう、ありがとう!echo 'Hi';後に追加するmysql_queryと表示されたので、次のクエリに問題がありました。私はその問題がばかげていることを知っていました。facepalm

誰が同じような間違いをしたことがありませんか?

于 2012-05-09T14:29:58.667 に答える
1

クエリがphpMyAdminで機能するが、コードからは機能しない場合、最初に行うことは変更です

SELECT `column` FROM `table`

SELECT `column` FROM `database`.`table`

UPDATE、またはもちろんクエリでも同様です。おそらくこれはあなたの修正であり、MySQLエラーは少し不可解です。

編集:

さらに、クエリのエスケープには使用しないhtmlspecialcharsでください。strip_tagsこれは意図された使用法ではないため、安全ではありません。クエリ値をエスケープするには、を使用することをお勧めしますmysql_real_escape_string。正しいアプリケーションには、正しいエスケープ機能を使用してください。私はあなたの質問を次のように書きます:

$query = '
    UPDATE `' . $masterapp_users_table . '`
    SET `login` = "' . mysql_real_escape_string($_POST['login']) . '",
    `pass` = "' . md5($_POST['pass']) . '",
    `email` = "' . mysql_real_escape_string($_POST['email']) . '",
    `firstname` = "' . mysql_real_escape_string($_POST['fn']) . '",
    `secondname` = "' . mysql_real_escape_string($_POST['sn']) . '"
    WHERE `login` = "' . mysql_real_escape_string($_POST['previouslogin']) . '"
';
// To display it in your browser:
echo htmlspecialchars($query) . '<br />';
// To run it:
mysql_query($query) or die(mysql_error());

これはただのフレンドリーなレッスンです。エスケープ機能が間違っていると、深刻なセキュリティホールが発生する可能性があります。

于 2012-05-09T16:03:32.530 に答える