mysql unknown column in where clause. a bug? - mysql

what can be the cause?
on the same DB the select statement works as expected:
select id from line where line.id = 298;
but the following delete statement fails:
delete from line where line.id = 298;
with an error:
Unknown column 'line_id' in 'where clause'
output of queries:
mysql> delete from line where line.id = 298;
ERROR 1054 (42S22): Unknown column 'line_id' in 'where clause'
mysql> select id from line where line.id = 298;
+-----+
| id |
+-----+
| 298 |
+-----+
1 row in set (0.00 sec)
mysql> describe line;
+--------------+---------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+---------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| service_id | int(11) | NO | MUL | NULL | |
| src_site_id | int(11) | NO | MUL | NULL | |
| dest_site_id | int(11) | NO | MUL | NULL | |
+--------------+---------+------+-----+---------+----------------+
4 rows in set (0.01 sec)

SHOW TRIGGERS;
If someone put a trigger without checking it on build (shame on him, that's a really bad thing to do), then it'll fail your query without telling you anything.
It's really tricky, because you can't see directly the error is trigger related, and if you don't use trigger /don't know they are some, the only way is to rebuild the table by yourself after a drop.

try creating an alias of the table you are deleting from:
DELETE FROM line l WHERE l.id = 298
this should work fine

Related

Error 1054 unknown column in 'field list'

when I execute the INSERT INTO account values(110,1250); statement on the following table
+--------+------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+------------+------+-----+---------+-------+
| acc_no | int(11) | YES | | NULL | |
| amount | bigint(20) | YES | | NULL | |
+--------+------------+------+-----+---------+-------+
I get this error
ERROR 1054 (42S22): Unknown column 'amount' in 'field list'
what can be the cause of it?
Trigger code is
create trigger demo before insert on account
for each row
set #diff=#diff+amount;
As I am learning triggers so I used a basic trigger defination
You have to put code like this:
INSERT INTO account values('110', '1250');
If you select varchar in mysql then it should be string. if you select INT in mysql then no need put ''.

MySQL/Python learning error

I am currently learning the basics of creating a database and doing some line of data analysis. i have been struggling to understand how to 'start coding'
so i finally decided to come up with a simple diary project to kick start my coding life.
Here is what i have so far, in terms of python so far nothing except i managed to link python and mysql.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| diary |
| mysql |
| performance_schema |
| sakila |
| sys |
| world |
+--------------------+
7 rows in set (0.00 sec)
mysql> desc diary;
+---------------+--------------+------+-----+-------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+-------------------+-------+
| TASK_COMMENTS | varchar(255) | YES | | NULL | |
| TASK | varchar(55) | NO | | NULL | |
| TS | timestamp | NO | | CURRENT_TIMESTAMP | |
+---------------+--------------+------+-----+-------------------+-------+
3 rows in set (0.00 sec)
mysql> select * from diary;
+---------------+---------------+---------------------+
| TASK_COMMENTS | TASK | TS |
+---------------+---------------+---------------------+
| NULL | Food Shopping | 2016-12-25 18:53:32 |
+---------------+---------------+---------------------+
1 row in set (0.00 sec)
here is the question finally:): Is it correct if i make the time stamp a primary key or is it more 'database error-free' to create an actual id instead of using automated timestamp as the pk?
also i am trying to make TASK_COMMENTS field not null aswell but i get this:
mysql> ALTER TABLE Diary MODIFY COLUMN TASK_COMMENTS VARCHAR(255) NOT NULL;
ERROR 1138 (22004): Invalid use of NULL value
Thank you for helping.
You can't alter the default value of a column to NOT NULL if a NULL value already exists. Either delete the row, or set it to something, then you can alter the column.
Using a timestamp is not a good idea for a primary key because it is very possible to get duplicate values. It's also easy not to, but it's just not a good idea. Use an id column, set the PK, and typically one would give it AUTO INCREMENT to ensure no duplicates.

Table 'XXX.pma__tracking' doesn't exist

I am very very confused right now, but somewhere along the lines phpMyAdmin has got confused.
SELECT tracking_active FROM `hutber`.`pma__tracking` WHERE db_name = 'hutber' AND table_name = 'exp_accessories' ORDER BY version DESC
#1146 - Table 'hutber.pma__tracking' doesn't exist
I cannot select db hutber, when I click on any of the tables i got the above error.
[Edit]
I then added the pma__tracking to the table and now I get this error:
SELECT tracking_active FROM `hutber`.`pma__tracking` WHERE db_name = 'hutber' AND table_name = 'exp_accessories' ORDER BY version DESC
#1054 - Unknown column 'db_name' in 'where clause'
How can I fix my DB?
mysql> SHOW TABLES; DESC pma__tracking;
+-------------------------------+
| Tables_in_hutber |
+-------------------------------+
| exp_accessories |
| exp_actions |
| exp_ajw_datagrab |
| exp_assets_files |
| pma__tracking |
+-------------------------------+
147 rows in set (0.00 sec)
+------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+-------------+------+-----+---------+-------+
| idpma__tracking | int(11) | NO | PRI | NULL | |
| tracking_active | varchar(45) | YES | | NULL | |
| pma__trackingcol | varchar(45) | YES | | NULL | |
+------------------+-------------+------+-----+---------+-------+
3 rows in set (0.01 sec)
Note: I created pma__tracking... Just so you know why the structure is like that.
1. #1146 - Table 'hutber.pma__tracking' doesn't exist
Since it is listed in SHOW TABLES; this could be a mysql permission issue (chmod, chown) in /var/lib/mysql. Ensure pma_tracking has the right permissions
chown mysql:mysql /path/to/mysql
sudo chmod -R 755 /var/lib/mysql/
2. #1054 - Unknown column 'db_name' in 'where clause'
DESC pma__tracking; clearly shows that there is no column as 'db_name'
, 'version', 'table_name' as mentioned select query

MySQL "Column count doesn't match value count" but the count DOES match

MySQL is issuing this error when I try to execute a query where the column count does match. Here is the structure of the table:
mysql> desc S_3068;
+-------------------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+----------------------+------+-----+---------+-------+
| SfmID | smallint(5) unsigned | NO | PRI | 1 | |
| DatValue | float | NO | | 0 | |
| DatRawValue | int(10) unsigned | NO | | 0 | |
| DatTime | int(10) unsigned | NO | PRI | 0 | |
| DatBusOrder | tinyint(3) unsigned | NO | PRI | 1 | |
| DatFormulaVersion | tinyint(3) unsigned | NO | | 0 | |
+-------------------+----------------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
I get the aforementioned error when I execute this query:
mysql> insert ignore into S_3068 values (133, 15.82, 5542, 1339309260, 0, 1);
ERROR 1136 (21S01): Column count doesn't match value count at row 1
As you can see, the column count does match the value count. Now what's even more puzzling is that the query works perfectly fine with SfmID = 132:
mysql> insert ignore into S_3068 values (132, 15.82, 5542, 1339309260, 0, 1);
Query OK, 1 row affected (0.00 sec)
SfmID being a unsigned smallint, that doesn't make any sense to me.
Any help on this matter would be greatly appreciated.
EDIT: The error was caused by a trigger associated to the table. Please see comments for more information.
The error was caused by a trigger associated to the table, doing a side insert on another table for value 133 but not for value 132. The error issued by MySQL was about the other table (which column count was indeed wrong) and not about the main table in which I was inserting data.

Converting MySQL warning into an error

Is there any way to convert the warning that MySQL is issuing about an invalid datetime into a hard error? I've tried using SET sql_mode='TRADITIONAL'; which apparently is supposed to turn (some) things that are warnings into errors, but it does not have any effect here. This is MySQL 5.1.56. Something that works on a session-level would be ideal, but I'll take what I can get.
mysql> describe test_table2;
+----------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| value | int(11) | YES | | NULL | |
| name | varchar(16) | YES | | NULL | |
| sometime | datetime | YES | | NULL | |
+----------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)
mysql> select * from test_table2;
+-------+-------+---------------------+
| value | name | sometime |
+-------+-------+---------------------+
| 1 | one | 2002-09-01 10:00:00 |
| 2 | two | 2002-09-02 11:00:00 |
| 3 | three | 2002-09-03 12:00:00 |
| 4 | four | 2002-01-04 13:00:00 |
| 5 | five | 2002-01-05 14:00:00 |
+-------+-------+---------------------+
5 rows in set (0.00 sec)
mysql> select * from test_table2 where sometime = 'foo';
Empty set, 2 warnings (0.00 sec)
Warning (Code 1292): Incorrect datetime value: 'foo' for column 'sometime' at row 1
Warning (Code 1292): Incorrect datetime value: 'foo' for column 'sometime' at row 1
With SET sql_mode='TRADITIONAL', doing an INSERT with an invalid date causes an error, but doing a SELECT with an invalid date still causes a warning. You can trigger the error by passing the (possibly invalid) date value to this query first:
CREATE TEMPORARY TABLE IF NOT EXISTS date_guard (date DATE) SELECT 'foo' AS date;
where 'foo' is the date value you want to validate.
Who is supposed to see the error?
If this is a fixed string 'foo' just try converting 'foo' to a date and see if you can a valid result (i.e. not 00-00-000). Do a pre-query to check the validity of the date, and then continue after.
I have not been able to make MySQL give an error in this case (or even convert the invalid date to a NULL - it insists on making it 00-00-0000).