Table 'XXX.pma__tracking' doesn't exist - mysql

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

Related

MYSQL after QA Migration to Maria DB, application query returns different cases for a column result set meta data

Were attempting to migrate some mysql servers to MariaDB on a new AWS (amazon-linux-2) instance.
After creating a new instance and installing mariadb we've dumped the old database via
mysqldump ... --add-drop-database --triggers --routines --events
and imported into the new system using
mysql -u root < dump.sql
The database has a table defined with mixture of uppercase and lower case columns e.g COLUMN1,COLUMN2,column3,etc
The original database, via mysqld -V, is mysqld Ver 14.14 Distrib 5.5.62, for Linux (x86_64)
The new database is, via mysqld -V, is mysqld Ver 15.1 Distrib 5.5.64-MariaDB, for Linux (x86_64)
installed with yum install mariadb-server
I've verified the schema's columns match for the table in question.
The accessing application queries the table with a select statement requesting the columns as lowercase.
(I've connected a local application and tested executing the same query against both database)
e.g. SELECT column1,column2,column3,etc from TABLE1 where ..
The results from the query from the original database respect the casing in the "select" statement from the application, however in the new mariadb database, the query results match the column casing as defined in the table.
Is there a setting that can be applied that will cause the result column names to respect the casing in the "SELECT" statement, and therefore cause the result column names returned by the same select statement in both databases to match?
A testcase under MariaDB and Mysql
select cname from (select s.CName from (select 'A' as CNAME) s) t;
Under MariaDB the result set column casing matches the column from the intermediary temp table.
With the same query using the source mysql database,
The result set column name's casing matches the casing in the select statement
It's always a bad practice not to use coding styles for SQL and mixing lowercase, uppercase or mixed case identifiers ("It was hard to write, therefore it should be hard to read"). There are several coding style guidelines, e.g. SQL Style Guide.
Beside that, you should also consider to upgrade to a more recent version of MariaDB/MySQL. MariaDB 5.5 will be eoled in 3 months.
But back to your problem:
Column identifiers are case insensitive, therefore the optimizer recognizes that your SQL statement can be simplified, in more recent versions of MariaDB the EXPLAIN EXTENDED and SHOW WARNINGS commands will give you more information:
MariaDB [(none)]> select version();
+--------------------------+
| version() |
+--------------------------+
| 10.5.1-MariaDB-debug-log |
+--------------------------+
MariaDB [(none)]> explain extended select cname from (select s.CName from (select 'A' as CNAME) s) t;
+------+-------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+------+-------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| 1 | PRIMARY | <derived3> | system | NULL | NULL | NULL | NULL | 1 | 100.00 | |
| 3 | DERIVED | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used |
+------+-------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
2 rows in set, 1 warning (0.00 sec)
MariaDB [(none)]> show warnings;
+-------+------+------------------------------------------------+
| Level | Code | Message |
+-------+------+------------------------------------------------+
| Note | 1003 | /* select#1 */ select 'A' AS `CName` from dual |
+-------+------+------------------------------------------------+
As you can see, the statement was optimized and transformed to select 'A' AS `CName` from dual.
Obviously in MariaDB 5.5 the optimizer was already more modern than the MySQL optimizer, but in recent version of MySQL you will get the same result:
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.13 |
+-----------+
1 row in set (0,00 sec)
mysql> explain select cname from (select s.CName from (select 'A' as CNAME) s) t;
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| 1 | PRIMARY | <derived3> | NULL | system | NULL | NULL | NULL | NULL | 1 | 100.00 | NULL |
| 3 | DERIVED | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
2 rows in set, 1 warning (0,00 sec)
mysql> show warnings;
+-------+------+------------------------------------------------+
| Level | Code | Message |
+-------+------+------------------------------------------------+
| Note | 1003 | /* select#1 */ select 'A' AS `CName` from dual |
+-------+------+------------------------------------------------+

I cannot change databases column

I cannot change databases column
My Env
MacOS Mojave, MySQL Server version: 10.1.39-MariaDB Source distribution
why
Making a CRUD app, but I want to change table column,
from text to desc, so I searched and used alter
command, but right SQL command returns error messages.
My table
MariaDB [cake_cms]> describe interns;
+----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| email | varchar(255) | NO | | NULL | |
| name | varchar(64) | NO | | NULL | |
| text | varchar(255) | NO | | NULL | |
| location | varchar(64) | YES | | NULL | |
+----------+--------------+------+-----+---------+----------------+
MariaDB [cake_cms]> Alter Table interns Rename Column text to desc;
ERROR 1064 (42000): You have an error in your SQL syntax;
check the manual that corresponds to your MariaDB server version
for the right syntax to use near 'Column text to desc' at line 1
Refered
https://www.dbonline.jp/mysql/table/index18.html
says to use
ALTER TABLE table_name
CHANGE COLUMN old_name TO new_name;
Rename a column in MySQL
This site says:
ALTER TABLE tableName RENAME COLUMN "oldcolname" TO "newcolname" datatype(length);
So I write
alter table interns rename column "name" to "newname" varchar(255);
But returned syntax error message....
I do not know what to do. Please help me!
desc is a sql command so you can't name your table like this

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.

mysql unknown column in where clause. a bug?

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

MySQL INSERT INTO failing at WHERE clause

Ok, I'm stumped on this one:
mysql> INSERT INTO item (col1) VALUES ('testing') WHERE item_name = 'server1';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE item_name = 'server1'' at line 1
Here's the table desc (slightly sanitized):
mysql> desc item;
+--------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| item_name | varchar(128) | YES | | | |
| active | int(11) | NO | | 0 | |
| col1 | varchar(512) | YES | | NULL | |
+--------------+--------------+------+-----+---------+----------------+
]I've tried some variations on the INSERT, but I've gotten nowhere. Look forward to someone revealing whatever obvious thing I'm missing!
Running: mysql Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1 (I know it's older, but I can't upgrade this box at the moment).
If you're looking to update an existing row, it's this:
UPDATE item
SET col1 = 'testing'
WHERE item_name = 'server1';
You're not using the INSERTstatement correctly, if you use VALUES clause you can't apply a WHERE condition on it.
Here is the same query with the appropriate syntax:
INSERT INTO item (col1)
SELECT 'testing'
FROM yourTable
WHERE item_name = 'server1';
Hope this will help you.