Related
I changed the datadir of a MySQL installation and all the bases moved correctly except for one.
I can connect and USE the database. SHOW TABLES also returns me all the tables correctly, and the files of each table exists on the MySQL data directory.
However, when I try to SELECT something from the table, I get an error message that the table does not exist. Yet, this does not make sense since I was able to show the same table through SHOW TABLES statement.
My guess is that SHOW TABLES lists file existence but does not check whether a file is corrupted or not. Consequently, I can list those files but not access them.
Nevertheless, it is merely a guess. I have never seen this before. Now, I cannot restart the database for testing, but every other application that uses it is running fine.
But that's just a guess, I've never seen this before.
Does anyone know why this is happening?
Example:
mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database |
+-----------------------+
| TABLE_ONE |
| TABLE_TWO |
| TABLE_THREE |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist
Just in case anyone still cares:
I had the same issue after copying a database directory directly using command
cp -r /path/to/my/database /var/lib/mysql/new_database
If you do this with a database that uses InnoDB tables, you will get this crazy 'table does not exist' error mentioned above.
The issue is that you need the ib* files in the root of the MySQL datadir (e.g. ibdata1, ib_logfile0 and ib_logfile1).
When I copied those it worked for me.
For me on Mac OS (MySQL DMG Installation) a simple restart of the MySQL server solved the problem. I am guessing the hibernation caused it.
I get this issue when the case for the table name I'm using is off. So table is called 'db' but I used 'DB' in select statement. Make sure the case is the same.
This error can also occur when setting lower_case_table_names to 1, and then trying to access tables that were created with the default value for that variable. In that case you can revert it to the previous value and you will be able to read the table.
I don't know the reason but in my case I solved just disabling and enabling the foreign keys check
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
stop mysqld
backup mysql folder: cp -a /var/lib/mysql /var/lib/mysql-backup
copy database folder from old machine to /var/lib/mysql
override ib* (ib_logfile* , ibdata ) from old database
start mysqld
dump dabase
mysqldump >dbase.mysql
stop mysql service
remove /var/lib/mysql
rename /var/lib/mysql-backup to /var/lib/mysql
start mysqld
create the database
mysqldump < dbase.mysql
Please run the query:
SELECT
i.TABLE_NAME AS table_name,
LENGTH(i.TABLE_NAME) AS table_name_length,
IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
information_schema.`TABLES` i
WHERE
i.TABLE_SCHEMA = 'database'
Unfortunately MySQL allows unicode and non-printable characters to be used in table name.
If you created your tables by copying create code from some document/website, there is a chance that it has zero-width-space somewhere.
I had the same problem and I searched for 2-3 days, but the solution for me was really stupid.
Restart the mysql
$ sudo service mysql restart
Now tables become accessible.
I have just spend three days on this nightmare. Ideally, you should have a backup that you can restore, then simply drop the damaged table. These sorts of errors can cause your ibdata1 to grow huge (100GB+ in size for modest tables)
If you don't have a recent backup, such as if you relied on mySqlDump, then your backups probably silently broke at some point in the past. You will need to export the databases, which of course you cant do, because you will get lock errors while running mySqlDump.
So, as a workaround, go to /var/log/mysql/database_name/ and remove the table_name.*
Then immediately try to dump the table; doing this should now work. Now restore the database to a new database and rebuild the missing table(s). Then dump the broken database.
In our case we were also constantly getting mysql has gone away messages at random intervals on all databases; once the damaged database were removed everything went back to normal.
Try to run sql query to discard tablespace before copying idb-file:
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Copy idb-file
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
Restart MySql
O.k. this is going to sound pretty absurd, but humor me.
For me the problem got resolved when I changed my statement to this :
SELECT * FROM `table`
I made two changes
1.) Made the table name lower case - I know !!
2.) Used the specific quote symbol = ` : It's the key above your TAB
The solution does sound absurd, but it worked and it's Saturday evening and I've been working since 9 a.m. - So I'll take it :)
Good luck.
What worked for me, was just dropping the table, even though it didnt exist. Then I re created the table and repopulated from an sql dump done previously.
There must be some metabase of table names, and it was most likely still existing in there till i dropped it.
Had a similar problem with a ghost table. Thankfully had an SQL dump from before the failure.
In my case, I had to:
Stop mySQL
Move ib* files from /var/mysql off to a backup
Delete /var/mysql/{dbname}
Restart mySQL
Recreate empty database
Restore dump file
NOTE: Requires dump file.
I had this problem after upgrading WAMP but having no database backup.
This worked for me:
Stop new WAMP
Copy over database directories you need and ibdata1 file from old WAMP installation
Delete ib_logfile0 and ib_logfile1
Start WAMP
You should now be able to make backups of your databases. However after your server restarts again you will still have problems. So now reinstall WAMP and import your databases.
After having to reinstall MySQL I had this same problem, it seems that during the install, some configuration files that store data about the InnoDB log files, these files ib_logfile* (they are log files right?), are overwriten. To solve this problem I just deleted the ib_logfile* files.
Do mysqldump to database:
mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
Restore database
mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
Now all tables in database were restored completely. Try..
SELECT * FROM dbname.tablename;
It appears that the issue has to do (at least in mine and a few others) with invalid (corrupt?) innodb log files. Generally speaking, they simply need to be recreated.
Here are solutions, most of which require a restart of mysql.
Recreate your log files (Delete and restart mysql)
Resize your log files (MySql 5.6+ will regenerate the file for you)
If you are doing some type of a data migration, make sure you have correctly migrated the right file and given it permissions as others have already stated
Check permissions of your data and log files, that mysql is owner of both
If all else fails, you will likely have to recreate the database
In my case, i had defined a trigger on the table and then was trying to insert the row in table. seems like, somehow trigger was erroneous, and hence insert was giving error, table doesn't exist.
Copy only ibdata1 file from your old data directory. Do not copy ib_logfile1 or ib_logfile0 files. That will cause MySQL to not start anymore.
Came cross same problem today. This is a mysql "Identifier Case Sensitivity" issue.
Please check corresponding data file. It is very likely that file name is in lower case on file system but table name listed in "show tables" command is in upper case. If system variable "lower_case_table_names" is 0, the query will return "table not exist" because name comparisons are case sensitive when "lower_case_table_names" is 0.
Its possible you have a hidden character in your table name. Those don't show up when you do a show tables. Can you do a "SHOW CREATE TABLE TABLE_ONE" and tab complete the "TABLE_ONE" and see if it puts in any hidden characters. Also, have you tried dropping and remaking the tables. Just to make sure nothing is wrong with the privileges and that there are no hidden characters.
I installed MariaDB on new computer,
stopped Mysql service
renamed data folder to data-
I solved my problem copying just
Mysql\data\table_folders and ibdata1
from crashed HD MySql data Folder to the new installed mysql data folder.
I Skipped ib_logfile0 and ib_logfile1 (otherwise the server did not start service)
Started mysql service.
Then server is running.
Same exact problem after TimeMachine backup import. My solution was to stop the MySQL server and fix read-write permissions on the ib* files.
One other answer I think is worth bringing up here (because I came here with that same problem and this turned out to be the answer for me):
Double check that the table name in your query is spelled exactly the same as it is in the database.
Kind of an obvious, newbie thing, but things like "user" vs "users" can trip people up and I thought it would be a helpful answer to have in the list here. :)
In my case, when I was importing the exported sql file, I was getting an error like table doesn't exist for the create table query.
I realized that there was an underscore in my database name and mysql was putting an escape character just before that.
So I removed that underscore in the database name, everything worked out.
Hope it helps someone else too.
Here is another scenario (version upgrade):
I reinstalled my OS (Mac OS El Captain) and installed a new version of mysql (using homebrew). The installed version (5.7) happened to be newer than my previous one. Then I copied over the tables, including the ib* files, and restarted the server. I could see the tables in mysql workbench but when I tried to select anything, I got "Table doesn't exist".
Solution:
stop the mysql server e.g. mysql.server stop or brew services stop mysql
start the server using mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (change path as needed)
run mysql_upgrade -u root -p password (in another terminal window)
shut down the running server mysqladmin -u root -p password shutdown
restart the server in normal mode mysql.server start or brew services start mysql
Relevant docs are here.
My table had somehow been renamed to ' Customers' i.e. with a leading space
This meant
a) queries broke
b) the table didn't appear where expected in the alphabetical order of my tables, which in my panic meant I couldn't see it!
RENAME TABLE ` Customer` TO `Customer`;
In my case it was SQLCA.DBParm parameter.
I used
SQLCA.DBParm = "Databse = "sle_database.text""
but it must be
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
Explaination :
You are going to combine three strings :
1. Database=' - "Database='"
2. (name of the database) - +sle_database.text+
3. ' - "'" (means " ' " without space)
Don't use spaces in quatermarks.
Thank to my colleague Jan.
Go to :xampp\mysql\data\dbname
inside dbname have tablename.frm and tablename.ibd file. remove it
and restart mysql and try again.
I had the same issue in windows.
In addition to copying the ib* files and the mysql directory under thd data directory, I also had to match the my.ini file.
The my.ini file from my previous installation did not have the following line:
innodb-page-size=65536
But my new installation did. Possibly because I did not have that option in the older installer.
I removed this and restarted the service and the tables worked as expected.
In short, make sure that the new my.ini file is a replica of the old one, with the only exception being the datadir, the plugin-dir and the port#, depending upon your new installation.
Hello Stackoverflow,
I was trying to connect to my MySQL database through Coda 2. I connected, created a database called 'database1' (for example), then I tried to create a table called 'user', but I get this error:
MySQL said: Table 'user' is read only
I was surprised because it had worked previously with other databases long time ago. I went to my xampp files, //xampp/mysql/data/database1/ and then I found out that user.ibd is there alone. So I first tried to change the properties of the files by disabling read-only. The problem is that when I did that, close the properties windows, and opened again I would get the read-only check box on. So I gave up on that. So I said ok, I will just create the database from my server instead. So I when to phpmyadmin, I see that database1 is created but there is no table called 'user'. So I try to create a table and I get this error:
#1813 - Tablespace for table '`database1`.`user`' exists. Please DISCARD the tablespace before IMPORT.
I then I found out I cannot even do much with phpmyadmin from my server. I tried reinstalling xampp, but it was impossible for me to remove the origianal because it was "already" in use. Please help me and thank you!
EDIT: I can apparently create databases but not tables. Just to clear that up.
You can try using CLI and logged into mysql and create a new database and a table. If it's working, there's something wrong with your phpmyadmin not mysql. Make sure you logged in as the same user (whom have root privileges) when creating the database and table.
I did an upgrade of Xampp to version 1.8.3-1
In phpMyAdmin, I can see my databases and the tables in them on the list on the left side.
But if I click any of my tables, I get and error #1146 table doesn't exist.
It is probably some kind of user access issue. But I haven't changed anything. I'm logging as root/no pw on mysql.
any idea?
thanks,
Benoit
If you changed the version of XAMPP you also chnaged the version of MySQL.
A straight copy of databases will probably not work.
You either need to backup under the old version and restore into the new version or use the mysql_upgrade processor.
Look up usage of mysql upgrade here mysql doc
You will need to find the page relating to the from-version and to-version of MySQL. It may even be required to go via a number of other versions of MySQL. So the backup and restore option os a lot easier.
Simple upgradation wont help, Following two steps will help you out:
Before upgrade , Go to the directory xampp/mysql/data ( or whatever is relevant to your OS) , and copy all the files starting with word ib, like ib_logfil0 etc. and paste to the upgraded version after upgrade.
Go to mysql command line, and run this command:
mysql_upgrade
I changed the datadir of a MySQL installation and all the bases moved correctly except for one.
I can connect and USE the database. SHOW TABLES also returns me all the tables correctly, and the files of each table exists on the MySQL data directory.
However, when I try to SELECT something from the table, I get an error message that the table does not exist. Yet, this does not make sense since I was able to show the same table through SHOW TABLES statement.
My guess is that SHOW TABLES lists file existence but does not check whether a file is corrupted or not. Consequently, I can list those files but not access them.
Nevertheless, it is merely a guess. I have never seen this before. Now, I cannot restart the database for testing, but every other application that uses it is running fine.
But that's just a guess, I've never seen this before.
Does anyone know why this is happening?
Example:
mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database |
+-----------------------+
| TABLE_ONE |
| TABLE_TWO |
| TABLE_THREE |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist
Just in case anyone still cares:
I had the same issue after copying a database directory directly using command
cp -r /path/to/my/database /var/lib/mysql/new_database
If you do this with a database that uses InnoDB tables, you will get this crazy 'table does not exist' error mentioned above.
The issue is that you need the ib* files in the root of the MySQL datadir (e.g. ibdata1, ib_logfile0 and ib_logfile1).
When I copied those it worked for me.
For me on Mac OS (MySQL DMG Installation) a simple restart of the MySQL server solved the problem. I am guessing the hibernation caused it.
I get this issue when the case for the table name I'm using is off. So table is called 'db' but I used 'DB' in select statement. Make sure the case is the same.
This error can also occur when setting lower_case_table_names to 1, and then trying to access tables that were created with the default value for that variable. In that case you can revert it to the previous value and you will be able to read the table.
I don't know the reason but in my case I solved just disabling and enabling the foreign keys check
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
stop mysqld
backup mysql folder: cp -a /var/lib/mysql /var/lib/mysql-backup
copy database folder from old machine to /var/lib/mysql
override ib* (ib_logfile* , ibdata ) from old database
start mysqld
dump dabase
mysqldump >dbase.mysql
stop mysql service
remove /var/lib/mysql
rename /var/lib/mysql-backup to /var/lib/mysql
start mysqld
create the database
mysqldump < dbase.mysql
Please run the query:
SELECT
i.TABLE_NAME AS table_name,
LENGTH(i.TABLE_NAME) AS table_name_length,
IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
information_schema.`TABLES` i
WHERE
i.TABLE_SCHEMA = 'database'
Unfortunately MySQL allows unicode and non-printable characters to be used in table name.
If you created your tables by copying create code from some document/website, there is a chance that it has zero-width-space somewhere.
I had the same problem and I searched for 2-3 days, but the solution for me was really stupid.
Restart the mysql
$ sudo service mysql restart
Now tables become accessible.
I have just spend three days on this nightmare. Ideally, you should have a backup that you can restore, then simply drop the damaged table. These sorts of errors can cause your ibdata1 to grow huge (100GB+ in size for modest tables)
If you don't have a recent backup, such as if you relied on mySqlDump, then your backups probably silently broke at some point in the past. You will need to export the databases, which of course you cant do, because you will get lock errors while running mySqlDump.
So, as a workaround, go to /var/log/mysql/database_name/ and remove the table_name.*
Then immediately try to dump the table; doing this should now work. Now restore the database to a new database and rebuild the missing table(s). Then dump the broken database.
In our case we were also constantly getting mysql has gone away messages at random intervals on all databases; once the damaged database were removed everything went back to normal.
Try to run sql query to discard tablespace before copying idb-file:
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Copy idb-file
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
Restart MySql
O.k. this is going to sound pretty absurd, but humor me.
For me the problem got resolved when I changed my statement to this :
SELECT * FROM `table`
I made two changes
1.) Made the table name lower case - I know !!
2.) Used the specific quote symbol = ` : It's the key above your TAB
The solution does sound absurd, but it worked and it's Saturday evening and I've been working since 9 a.m. - So I'll take it :)
Good luck.
What worked for me, was just dropping the table, even though it didnt exist. Then I re created the table and repopulated from an sql dump done previously.
There must be some metabase of table names, and it was most likely still existing in there till i dropped it.
Had a similar problem with a ghost table. Thankfully had an SQL dump from before the failure.
In my case, I had to:
Stop mySQL
Move ib* files from /var/mysql off to a backup
Delete /var/mysql/{dbname}
Restart mySQL
Recreate empty database
Restore dump file
NOTE: Requires dump file.
I had this problem after upgrading WAMP but having no database backup.
This worked for me:
Stop new WAMP
Copy over database directories you need and ibdata1 file from old WAMP installation
Delete ib_logfile0 and ib_logfile1
Start WAMP
You should now be able to make backups of your databases. However after your server restarts again you will still have problems. So now reinstall WAMP and import your databases.
After having to reinstall MySQL I had this same problem, it seems that during the install, some configuration files that store data about the InnoDB log files, these files ib_logfile* (they are log files right?), are overwriten. To solve this problem I just deleted the ib_logfile* files.
Do mysqldump to database:
mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
Restore database
mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
Now all tables in database were restored completely. Try..
SELECT * FROM dbname.tablename;
It appears that the issue has to do (at least in mine and a few others) with invalid (corrupt?) innodb log files. Generally speaking, they simply need to be recreated.
Here are solutions, most of which require a restart of mysql.
Recreate your log files (Delete and restart mysql)
Resize your log files (MySql 5.6+ will regenerate the file for you)
If you are doing some type of a data migration, make sure you have correctly migrated the right file and given it permissions as others have already stated
Check permissions of your data and log files, that mysql is owner of both
If all else fails, you will likely have to recreate the database
In my case, i had defined a trigger on the table and then was trying to insert the row in table. seems like, somehow trigger was erroneous, and hence insert was giving error, table doesn't exist.
Copy only ibdata1 file from your old data directory. Do not copy ib_logfile1 or ib_logfile0 files. That will cause MySQL to not start anymore.
Came cross same problem today. This is a mysql "Identifier Case Sensitivity" issue.
Please check corresponding data file. It is very likely that file name is in lower case on file system but table name listed in "show tables" command is in upper case. If system variable "lower_case_table_names" is 0, the query will return "table not exist" because name comparisons are case sensitive when "lower_case_table_names" is 0.
Its possible you have a hidden character in your table name. Those don't show up when you do a show tables. Can you do a "SHOW CREATE TABLE TABLE_ONE" and tab complete the "TABLE_ONE" and see if it puts in any hidden characters. Also, have you tried dropping and remaking the tables. Just to make sure nothing is wrong with the privileges and that there are no hidden characters.
I installed MariaDB on new computer,
stopped Mysql service
renamed data folder to data-
I solved my problem copying just
Mysql\data\table_folders and ibdata1
from crashed HD MySql data Folder to the new installed mysql data folder.
I Skipped ib_logfile0 and ib_logfile1 (otherwise the server did not start service)
Started mysql service.
Then server is running.
Same exact problem after TimeMachine backup import. My solution was to stop the MySQL server and fix read-write permissions on the ib* files.
One other answer I think is worth bringing up here (because I came here with that same problem and this turned out to be the answer for me):
Double check that the table name in your query is spelled exactly the same as it is in the database.
Kind of an obvious, newbie thing, but things like "user" vs "users" can trip people up and I thought it would be a helpful answer to have in the list here. :)
In my case, when I was importing the exported sql file, I was getting an error like table doesn't exist for the create table query.
I realized that there was an underscore in my database name and mysql was putting an escape character just before that.
So I removed that underscore in the database name, everything worked out.
Hope it helps someone else too.
Here is another scenario (version upgrade):
I reinstalled my OS (Mac OS El Captain) and installed a new version of mysql (using homebrew). The installed version (5.7) happened to be newer than my previous one. Then I copied over the tables, including the ib* files, and restarted the server. I could see the tables in mysql workbench but when I tried to select anything, I got "Table doesn't exist".
Solution:
stop the mysql server e.g. mysql.server stop or brew services stop mysql
start the server using mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (change path as needed)
run mysql_upgrade -u root -p password (in another terminal window)
shut down the running server mysqladmin -u root -p password shutdown
restart the server in normal mode mysql.server start or brew services start mysql
Relevant docs are here.
My table had somehow been renamed to ' Customers' i.e. with a leading space
This meant
a) queries broke
b) the table didn't appear where expected in the alphabetical order of my tables, which in my panic meant I couldn't see it!
RENAME TABLE ` Customer` TO `Customer`;
In my case it was SQLCA.DBParm parameter.
I used
SQLCA.DBParm = "Databse = "sle_database.text""
but it must be
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
Explaination :
You are going to combine three strings :
1. Database=' - "Database='"
2. (name of the database) - +sle_database.text+
3. ' - "'" (means " ' " without space)
Don't use spaces in quatermarks.
Thank to my colleague Jan.
Go to :xampp\mysql\data\dbname
inside dbname have tablename.frm and tablename.ibd file. remove it
and restart mysql and try again.
I had the same issue in windows.
In addition to copying the ib* files and the mysql directory under thd data directory, I also had to match the my.ini file.
The my.ini file from my previous installation did not have the following line:
innodb-page-size=65536
But my new installation did. Possibly because I did not have that option in the older installer.
I removed this and restarted the service and the tables worked as expected.
In short, make sure that the new my.ini file is a replica of the old one, with the only exception being the datadir, the plugin-dir and the port#, depending upon your new installation.
I am using windows XP. I am creating a table in phpMyAdmin using its built-in create table feature,
my database name is ddd.
It generates the following code:
CREATE TABLE `ddd`.`mwrevision` (
`asd` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`sddd` INT NOT NULL
) ENGINE = INNODB;
and the following error shows up:
MySQL said:
#1146 - Table 'ddd.mwrevision' doesn't exist
What might be the problem?
I also had same problem in past. All had happend after moving database files to new location and after updating mysql server. All tables with InnoDB engine disappeared from my database. I was trying to recreate them, but mysql told me 1146: Table 'xxx' doesn't exist all the time until I had recreated my database and restarted mysql service.
I think there's a need to read about InnoDB table binaries.
I had the same problem and can't get a good tip for this over the web, so I shared this for you and for all who needs.
In my situation I copy a database (all files: frm, myd) to the data folder in MySQL data folder (using Wamp at home). All thing was OK until I want to create a table and have the error #1146 Table '...' doesn't exist!.
I use Wamp 2.1 with MySQL version 5.5.16.
My solution:
Export the database to file;
verify if exported file is really OK!!;
drop the database where I have issues;
create a new database with the same name that the last;
import the file to the database.
FOR ME IS PROBLEM SOLVED. Now I can create tables again without errors.
Restarting MySQL works fine for me.
In my case I ran this command even if the table wasn't visible in PhpMyAdmin :
DROP TABLE mytable
then
CREATE TABLE....
Worked for me !
Check filenames.
You might need to create a new database in phpmyadmin that matches the database you're trying to import.
I had the same problem. I tried to create a table in mysql and got the same error. I restarted mysql server and ran the command and was able to create/migrate table after restating.
Today i was facing same problem. I was in very difficult situation but what id did i create a table with diffrent name e.g (modulemaster was not creating then i create modulemaster1) and after creating table i just do the rename table.
I encountered the same problem today. I was trying to create a table users, and was prompted that ERROR 1146 (42S02): Table users doesn't exist, which did not make any sense, because I was just trying to create the table!!
I then tried to drop the table by typing DROP TABLE users, knowing it would fail because it did not exist, and I got an error, saying Unknown table users. After getting this error, I tried to create the table again, and magically, it successfully created the table!
My intuition is that I probably created this table before and it was not completely cleared somehow. By explicitly saying DROP TABLE I managed to reset the internal state somehow? But that is just my guess.
In short, try DROP whatever table you are creating, and CREATE it again.
As pprakash mentions above, copying the table.frm files AND the ibdata1 file was what worked for me.
In short:
Shut your DB explorer client (e.g. Workbench).
Stop the MySQL service (Windows host).
Make a safe copy of virtually everything!
Save a copy of the table file(s) (eg mytable.frm) to the schema data folder (e.g. MySQL Server/data/{yourschema}).
Save a copy of the ibdata1 file to the data folder (i.e., MySQL Server/data).
Restart the MySQL service.
Check that the tables are now accessible, queryable, etc. in your DB explorer client.
After that, all was well. (Don't forget to backup if you have success!)
Column names must be unique in the table. You cannot have two columns named asd in the same table.
run from CMD & %path%=set to mysql/bin
mysql_upgrade -u user -ppassword
Recently I had same problem, but on Linux Server. Database was crashed, and I recovered it from backup, based on simply copying /var/lib/mysql/* (analog mysql DATA folder in wamp). After recovery I had to create new table and got mysql error #1146. I tried to restart mysql, and it said it could not start. I checked mysql logs, and found that mysql simply had no access rigths to its DB files. I checked owner info of /var/lib/mysql/*, and got 'myuser:myuser' (myuser is me). But it should be 'mysql:adm' (so is own developer machine), so I changed owner to 'mysql:adm'. And after this mysql started normally, and I could create tables, or do any other operations.
So after moving database files or restoring from backups check access rigths for mysql.
Hope this helps...
The reason I was facing this was because I had two "models.py" files which contained slightly different fields.
I resolved it by:
deleting one of the models.py files
correcting references to the deleted file
then running manage.py syncdb
I got this issue after copying mytable.idb table file from another location. To fix this problem I did the following:
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Copy mytable.idb
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
Restart MySql
I had the same issue. It happened after windows start up error, it seems some files got corrupted due to this. I did import the DB again from the saved script and it works fine.
I had this problem because of a trigger not working..Worked after I deleted the trigger.
In my case, MySQL's parameter; lower_case_table_names was configured = 0.
It causes queries related with using upper cases will not work.
For me it was a table name upper/lower case issue. I had to make sure that table case name matched in a delete query, table notifications was not the same as Notifications. I fixed it by matching table name case with query and what MySQLWorkbench reported.
What is wierd is that this error showed up in a worked sql statement. Don't know what caused this case sensitivity. Perhaps an auto AWS RDS update.
if you are modifying mysql bin->data dir's and after that, your database import will not works
so you need to close wamp and after that start wamp
now database import will work fine
Make sure you do not have a trigger that is trying to do something with the table mentioned in the error. I was receiving Error Code: 1146. Table 'exampledb.sys_diagnotics' doesn't exist on insert queries to another table in my production database. I exported the table schemas of my production database then searched for instances of exampledb.sys_diagnotics the schema SQL and found a debugging insert statement I had added to a table trigger in my development environment but this debug statement had been copied to production. The exampledb.sys_diagnotics table was not present on my production database. The error was resolved by removing the debug statement in my table trigger.