I got error 1812 on mysql after renaming a primary key. (mysqld 8.0.29 on Centos 7) Please excuse my English.
First I created a table with id as the primary key on PHPMyAdmin. Then after some quick consideration I changed it to code, as soon as I hit the apply button, I got "tablespace is missing" error. Luckily this table is still empty, but the weird thing is now it said I have ~4,294,967,295 rows in that table.
Now I can not do anything to that specific table, drop or copy or rename or anything because the tablespace is missing. I can't even do mysqldump to the database because of that table.
I searched through stackoverflow, some people got this error after copying the idb files from another machine, I didn't copy it from other machine or databases or any files, all was running normal before this error.
This are what I have tried:
I tried to dump the db to a file, and got the error "mysqldump: Got error: 1812: Tablespace is missing for table tablename.", even with -f option.
Another solution suggest to rename/delete the idb file and restart, did that and nothing is changed (i use seperated idb files -- innodb_file_per_table = ON)
I've Checked the ownership and permission. It is mysql:mysql so I think it's all good.
Tried the ALTER TABLE tablename DISCARD TABLESPACE; got the "tablespace is missing" running that command.
Create dummy table and rename the idb to the corrupt table, chown, restart the service, still nothing is changed.
Create tablespace manually and assigned it to the table, restart the service and nothing change.
Restart the service, even restarting the server didn't help.
Tried the "Repair" option on phpmyadmin, and got this error (tablespace is missing, table not exist, corrupt)
My other table on that database is still working normally, and all other databases too. So I can just use another table name and ignore that. But I want that table removed, or at least so I can do mysqldump for backup routine (now I just create a snapshot of the server every day for backup)
Thank you in advance
I'm using MAMP and I already created a "my.cnf" file inside Applications/MAMP/conf with a high value of max_allowed_packet. But, everytime a try to drop my database, this error occurs, all tables are deleted, but the schema isn't. How can I force my db to be dropped?
I checked the file mysql_error_log.err in Applications/MAMP/logs. The problem was a missing index on a foreign key in a table. I added this index and the problem didn't happen again.
I have this situation. The site that I'm working with has MySQL configured without InnoDB. My Ubuntu localhost has MySQL server running with InnoDB.
Question: If I export the MySQL database of the remote site and import it to my local Ubuntu MySQL , will that work without any issues? Supposing I export it using the mysql command line mysqldump and restore it via command line too. The database is a bit large so I need to check first whether this will work.
I'm planning to import it locally so I can test the site for the functionalities needed. Please let me know if this plan will work. Thanks :)
First if mysqldump have engine=InnoDB statement in CREATE TABLE block, Then it could possible to import failure if Local MySQL is not configured to use InnoDB (I personally think InnoDB is always available, However it could be non default engine).
After successful import, It may be automatically converted to default MyISAM Engine. So All foreign keys and InnoDB related objects will not imported in this case. Now if your application very much depend on DB based Foreign keys mechanism, Then it can broke. Otherwise things should work like before.
Personally I imported InnoDB databases before end they automatically converted to MyISAM. Application work seemlessly as That manage constraints on Application side (in MVC Models).
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.
I have a production and a development server, each server has its own MySql server. I am not the admin of any server, not installed anything. I need to get the schema and data from the production to the development but myslqdump does not restore any data!
I tried to add SET FOREIGN_KEY_CHECKS = 0; without result. Then I removed the only trigger present, nothing. Then I removed two foreign keys that created and error (when importing phpMyAdmin). Then I was able to import the data.
This is quite scaring. I cannot rely on mysqldump, isn't? Did you have similar problems? Any advise?
are you dumping and restoring with phpmyadmin? what error do you get?
for large mysql databases i recommend to user mysqldumper for dumping and restoring if you have no ssh access.
http://www.mysqldumper.net/