Home/ Questions/Q 7911157
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T13:08:49+00:00

Yeah, I know, its common problem, but I cant solve it for last 3

  • 0

Yeah, I know, its common problem, but I cant solve it for last 3 hours.

I do this query:

$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());

and I get this:

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

But it changes the record!
Maybe someone can see what I cant see?

Oh! forgot to say: If I paste that string from browser to PMA, it works fine.

UPDATE:

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 ;
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The error means that the column in the MasterApp_Users table is not called login; it is Login or LOGIN or log_in or user or username or user_name or …

    In the statement that constructs the string, you have back-ticks:

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

    In the echo, those back-ticks aren’t showing.

    If you use back-ticks like that, the column names become case-sensitive. What was the spelling of the CREATE TABLE statement precisely? Were column names written in mixed case inside back-ticks?

    …Now we have the table schema shown, it is less explicable (not that it was easily explained before)…

    Are you sure your browser and your PHP are connecting to the same database?

    To debug further, I suggest changing:

    • The WHERE criterion to specify the id column and an appropriate value.
    • Do not SET the login column.

    Check whether the UPDATE changes what you expect it to change.

    If it doesn’t change the record you think it should (but it does work), you have an issue identifying the database.

    If you end up with a different column not being found, we can be pretty sure that there’s a different table altogether. Maybe do a SELECT * FROM masterapp_users and review the column definitions returned.

    If it changes the record, then we have a deep mystery on our hands.

    It changes the record.

    The complaint was specifically about the login column in the WHERE clause. If you specify id in the WHERE clause, are you able to set login in the SET clause of the statement?

    If so, this is beginning to look like a bug in the DBMS. It is difficult to see why it could complain about login in WHERE and not in SET. Thus, it is unlikely to be the solution.

    If the message changes to something roughly equivalent to ‘unknown column login in the SET clause’, then there is some self-consistency.

    What happens if you rename the column in the table and modify the code accordingly?

    Resolution

    Comment 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?

    Comment 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

    Who’s never made a similar mistake?

    • 0