When you do a query against a table setting it with an alias, and then click on the "delete" button, the confirm box displays an incorrect SQL sentence which will fail to delete the row.
The reason is that it will preserve the name of the columns as alias.column, but will use just the table name in the from clause, giving a "table not found" error.
I attach a screen where youcan see the SQL query I performed and the query with which phpMyAdmin attempts to delete a row.
Bug example
Logged In: YES
user_id=210714
Originator: NO
Are you sure this is with phpMyAdmin 2.10.3? I cannot reproduce the problem with my 2.10.3.
Logged In: YES
user_id=1028008
Originator: YES
Indeed, the phpMyAdmin's index says it is version 2.10.3.0 (2007-07-20)
Logged In: YES
user_id=210714
Originator: NO
Ok, please describe your server:
- MySQL version
- PHP version
Logged In: YES
user_id=1028008
Originator: YES
MySQL version 5.0.48
PHP version 5.2.5
Logged In: YES
user_id=1028008
Originator: YES
I just recreated the bug on a different system.
This time it was phpMyAdmin 2.10.0.2 with MySQL 4.1.22 and PHP 5.2.4
Hope anything of this helps you find the source.
Logged In: YES
user_id=210714
Originator: NO
1. Are you able to reproduce this on our demo server http://www.phpmyadmin.net/home_page/demos.php (stable release)?
2. Can you attach here a small export of your tables and data on which you can reproduce the problem?
Table dump with data used in the example
Logged In: YES
user_id=1028008
Originator: YES
No, I can't reproduce the bug in the test server's stabel version (2.11.3). With this version the query uses the table's name and not the alias for the delete statement, making it valid. It seems a problem of the 2.10 branch only....
And yes, I'm attaching the table and data used in the screenshot I first submitted. I can't think of anything special about it, I reproduced the bug with every other table I have on two different systems... the only thing that never changed in these tests (that I can think of) is that every table used the MyISAM storage engine, but I doubt that has any relevance to the generation of a delete sql query, but you should know better.
File Added: foros.sql.zip
Logged In: YES
user_id=210714
Originator: NO
Thanks for testing in 2.11.3. I'll close this (we don't work to fix bugs in older branches).