After renaming one of my MySQL 5.1 MyISAM tables from test_tablename to tablename, I have found that if I try to execute an INSERT (or REPLACE) query, I get the following message:
INSERT INTO tablename (...) VALUES (...)
1146: Table 'dbname.test_tablename' doesn't exist
I have triple-checked my database abstraction code, and verified this by running the query directly on the server.
According to the MySQL server, the CREATE TABLE syntax is tablename, as expected, and when I run SHOW TABLES, it lists tablename as expected.
Is there any reason for this to happen?
More importantly, is there an easier way to fix this than dumping, dropping, re-creating, and reloading the table?
This is likely to be caused by a trigger that has not been updated accordingly.
If you renamed test_tablename to tablename, shouldn't the following be true ?
1146: Table 'dbname.test_tablename' doesn't exist
Be sure to use tablename in your queries, not test_tablename.
Are you sure you are not inserting into a view that still references test_tablename?
Related
Table storage engine for <TABLE> doesn't have this option.
This is the error returned by MySQL on an order by query. The column type is varchar(2000).
Query:
select * from `dbo.table_1` order by textT;
Error returned:
ERROR 1031 (HY000): Table storage engine for 'dbo.table_1' doesn't have this option.
Why does this happen? And how can I fix it?
This problem appears to occur when you're importing a table definition that had been created with MyISAM but later was switched to InnoDB; the resulting ROW_FORMAT options appear to be invalid.
If you're trying to import an exported database and encounter this problem, you can simply search and replace ROW_FORMAT=FIXED with nothing.
I used the following to do so really quickly:
sed -ie 's/ROW_FORMAT=FIXED//g' backup.sql
Problem solved! Thanks to jbrahy for pointing out that it was the ROW_FORMAT that was the problem.
EDIT: Updated to work for more platforms as per #seven's suggestion
EDIT2: Also note, as per #Steen-Schütt, this may be a safer fix
sed -ie 's/ROW_FORMAT=FIXED/ROW_FORMAT=COMPACT/g' backup.sql
You can also try this:
ALTER TABLE `dbo.table_1` ROW_FORMAT = DEFAULT ;
I get the same error when I import a table definition that's InnoDB with ROW_FORMAT=DYNAMIC in it. The table was created with a MyISAM engine but I later switched it to InnoDB. When I removed the ROW_FORMAT=DYNAMIC from the create table statement and recreated the table it worked fine. My solution to your problem would be this.
show create table `dbo.table_1`;
then take the output from that command and remove the ROW_FORMAT=DYNAMIC then rename the table to dbo.table_1_old
rename table `dbo.table_1` to `dbo.table_1_old`;
Then execute the create table statement from the first step i.e.
-- don't use this create as there are missing columns use yours
create table `dbo.table_1` (textT VARCHAR(255));
Then repopulate your table with the old data.
insert into `dbo.table_1` select * from `dbo.table_1_old`;
Then you should be able to execute your original SQL
select * from `dbo.table_1` order by textT;
This problem appears to occur when you're importing a table definition to MySQL 5.7 that had been created with MySQL 5.6 and earlier. The same error can produceb by option KEY_BUFFER_SIZE=8192 and similar sizes defined in bytes for INNODB ENGINE.
I had this error when I'm importing base from sql-dump.
Decision: sed -ie 's/KEY_BLOCK_SIZE=16384//g' my-file-sql_dump.sql
I was facing this problem and my backup file was encrypted .zsql file. So I modified my.cnf by adding innodb_strict_mode = off. It worked fine
I'm using the following query to replace old link with a new one:
UPDATE my_table SET file = 'link' WHERE my_table.file ='old_link';
In my tests I can't duplicate that and I'm not sure what's wrong with that query, but apparently sometimes it leaves the old entry and inserts a new one instead of updating!
mysql ver:
5.6.12-56 Percona Server, table type: innodb
The query looks fine to me. UPDATE should never create new rows, only modify existing rows. The problem is probably in another part of the code.
Although an UPDATE won't fire an insert in its own, there could exist triggers in the database that would fire an INSERT whenever a record gets updated.
Here are some links that you should check:
CREATE TRIGGER Syntax
Trigger Syntax and Examples
I have an SQL database called copra4server, with a table called db_version.
I enter:
USE copra4server;
SELECT version FROM db_version;
And I get ERROR 1146 (42S02): Table 'copra4server.db_version' doesn't exist
Why is it trying to get a table named dbname.tablename and what does this dot notation mean?
The error is very clear. Your table db_version is not present in the copra4server database.
When you are saying USE copra4server; then it means that you want to use your copra4server database
And when you select from the table db_version the table is not present hence results in the error.
I think you are a bit confused about "databases" versus "database servers".
MySQL is a database server. You can connect to it and see databases. Note the plural here. One server, many databases.
One of the databases on your server is called copra4server. When you say:
USE copra4server
You are saying "my current database is now copra4server". So, any table you reference will be assumed to be in that database. Your query:
SELECT version FROM db_version;
Is really -- under the hood -- saying
SELECT version FROM copra4server..db_version;
And, the table does not exist, causing the error message.
By the way, if you are looking for the database version, the proper syntax is:
SELECT version()
That's how MySQL refers to tables (db.table) so it is clear that it is talking about the table in that db.
Check your spelling if you're sure the table exists.
We have mysql v5.0.77 running on a server collecting some measurement data.
On the mysql server, we have the following databases:
raw_data_db
config_tables_db
processed_data_db
We ONLY want to replicate the 'processed_data_db' which is constructed using information from the 'raw_data_db' and 'config_tables_db'.
We keep getting errors on our slave server when it tries to duplicate the statements that are constructing the processed data.
Example:
[ERROR] Slave: Error 'Table 'raw_data_db.s253' doesn't exist' on query. Default database: 'data'. Query: 'CREATE TEMPORARY TABLE temp SELECT * FROM raw_data_db.s253 WHERE DateTimeVal>='2011/04/21 17:00:00' AND DateTimeVal<='2011/04/21 17:10:00'', Error_code: 1146
What I am assuming is happening is that the cross-db selects can't find the raw database because we aren't replicating it, and the data do not exist on the slave...or something along those lines?
So I tried using ignores, but we're still getting the errors
replicate-wild-ignore-table = raw_data_db.*
replicate-wild-ignore-table = data.temp*
Other configuration information:
replicate-rewrite-db = processed_data_db->data
replicate-do-db = data
Is it possible to replicate just the one database if all the tables are created from references to other databases? Any ideas on how to get around this error?
I looked in to row-based replication which seemed like it might do the trick, but it's only available in v5.1 or greater....is there anything similar in earlier versions?
I fixed the ignore table statements to "data.%temp%", and it seems to be ignoring just fine, but I still can't replicate the tables I want because the insert statement is now referencing a table that doesn't exist.
ex.
Error 'Table 'data.temp' doesn't exist' on query. Default database: 'data'. Query: 'INSERT INTO abc SELECT FROM_UNIXTIME(AVG(UNIX_TIMESTAMP(DateTimeVal))), ROUND(AVG(Difference),3), ROUND(STDDEV(Difference),3), ROUND(AVG(Frequency),0), ROUND(AVG(SignalPower),1) FROM temp WHERE ABS(Difference)<'10000.0' AND Difference!='0''
The processing is creating temporary tables from the raw database and then averaging all the values in the temporary table and inserting the result in to the processed_data_db, but since I'm ignoring the create statements, it doesn't have access to those tables, but the reason I'm ignoring them in the first place is because they reference tables outside of what I want to replicate...so I'm not sure how I should approach this....any suggestions would be greatly appreciated.
Temporary tables and replication
options. By default, all temporary
tables are replicated; this happens
whether or not there are any matching
--replicate-do-db, --replicate-do-table, or --replicate-wild-do-table options in effect. However, the
--replicate-ignore-table and --replicate-wild-ignore-table options are honored for temporary tables.
http://dev.mysql.com/doc/refman/5.0/en/replication-features-temptables.html
edit:
replicate raw_data_db and config_tables_db tables which using
in you insert query
use drbd protocol
http://www.mysql.com/why-mysql/drbd/
I was suggested to do this
SELECT table_schema, table_name FROM information_schema.tables
WHERE table_schema = 'mydb' AND table_name='ApprovePost';
However it is not reliable and cause me errors on several versions of mysql on windows and linux.
Maybe there is another way. Does anyone know?
This issue is I can do create table if not exists but I do a second pass to add the FK constraint. In my SQL dump I see > 130 contains on a single table. The table only has 6 columns, only two of these need constrains. The constrains keep building and building every time I restart the Apache server or whenever mono feels the need to call my global init method in my webapp.
Looks like you need to use the FLUSH TABLES command for the INFORMATION_SCHEMA.TABLES to reflect existing tables.
Reference:
TABLE CACHE
If your only actual problem now is recreating the foreign key constantly (aside from a possibly broken MySQL install considering your other troubles), why not:
1) give it a constraint symbol (should be unique in database) and let the adding fail silently / catch 'em?
ALTER TABLE tbl ADD CONSTRAINT only_one_please FOREIGN KEY (columnname) ...
2) or better yet, add the foreign key clause in your create table in the first place?
As for the original question: I know no reason why this should happen, and I cannot recreate it. Selecting from information_schema is afaik quite the preferred way of checking this, and hasn't failed me yet. Aside from a brute force check like SELECT * FROM tablename LIMIT 0; and checking for errors, you first might want to check for any other caching mechanisms besides MySQL's query cache, and if they're not there / not the problem, perhaps try a SELECT SQL_NO_CACHE table_schema, table_name FROM information_schema.tables.