phpMyAdmin Error #1932: Table Doesn't Exist in Engine

XAMPP's MySQL refused to start, so you followed the usual advice and copied C:\xampp\mysql\backup over C:\xampp\mysql\data, or reinstalled XAMPP and copied your old database folder across. MySQL starts again, your shop_db database shows its tables in the sidebar, and clicking orders gives you mysql phpmyadmin: error #1932 - table doesn't exist in engine.

The usual causes:

• Your table files were copied without ibdata1. The table's .frm and .ibd files exist, but the shared file that registers them with InnoDB is new or missing.
• phpMyAdmin's own pma__ tables are broken. The error names phpmyadmin.pma__something, not your table.
• An upgrade or crash left the system tables out of sync. The error appears on tables in the mysql database, or right after changing versions.

In most XAMPP cases, error #1932 means InnoDB doesn't recognise table files that are sitting in the folder. Stop MySQL, copy the old ibdata1 and your database folder from the previous install into C:\xampp\mysql\data, then start MySQL again. If you don't have the old ibdata1, import each .ibd file manually.

What MySQL phpMyAdmin: error #1932 - table doesn't exist in engine means

Two things have to agree before InnoDB opens a table. The table's files must exist in the database folder, and InnoDB's internal data dictionary must list the table.

On the MariaDB versions that XAMPP ships, that dictionary lives in C:\xampp\mysql\data\ibdata1. Your orders table is stored in shop_db\orders.frm (structure) and shop_db\orders.ibd (data). phpMyAdmin lists tables by reading the folder, so orders still appears. InnoDB checks ibdata1, can't find orders, and returns #1932.

That's why copying "just the database folder" never works for InnoDB tables. MyISAM tables survive it; InnoDB tables don't.

Quick fix: put the matching ibdata1 back

This works when the old data folder still exists, for example C:\xampp_old\mysql\data or a backup copy.

1. Stop MySQL in the XAMPP Control Panel.
2. Back up the current data folder. Don't skip this.

xcopy C:\xampp\mysql\data C:\xampp\mysql\data_before_fix /E /I /H

1. Copy the old ibdata1 and your database folder into the live data folder:

copy /Y C:\xampp_old\mysql\data\ibdata1 C:\xampp\mysql\data\ibdata1
xcopy C:\xampp_old\mysql\data\shop_db C:\xampp\mysql\data\shop_db /E /I /H /Y

1. Start MySQL and open shop_db.orders in phpMyAdmin.

Gotcha: the old ibdata1 only knows about tables that existed in the old install. Any InnoDB table you created after the switch will now throw #1932 instead. Export those tables before you swap the file.

The old and new installs should run the same MariaDB version. If MySQL won't start after the swap, check the error log (covered below) before trying anything else.

Also stop following the "copy the backup folder over data" fix for a MySQL crash. That backup folder contains a fresh ibdata1, and it's exactly how many people end up here.

Cause 1: table doesn't exist in engine after copying the data folder

How to confirm it

Open C:\xampp\mysql\data\mysql_error.log and search for your table name. You'll usually see a line saying the table doesn't exist in the InnoDB data dictionary, or that InnoDB can't open the tablespace. Also check the folder: if orders.ibd is there and has a realistic size, your data is probably still recoverable.

Fix: re-import the .ibd file when ibdata1 is gone

This needs innodb_file_per_table to have been on when the table was created, which gives every table its own .ibd file. It's the default on modern versions. You also need the exact table structure. For a Laravel project, your migrations already have it.

1. Stop MySQL, then move orders.frm and orders.ibd out of C:\xampp\mysql\data\shop_db into a safe folder.
2. Start MySQL and recreate the table with the same structure, using the same columns, indexes and row format:

USE shop_db;

CREATE TABLE orders (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  customer_id BIGINT UNSIGNED NOT NULL,
  total DECIMAL(10,2) NOT NULL,
  created_at TIMESTAMP NULL,
  updated_at TIMESTAMP NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;

In Laravel, running only the relevant migration does the same job. If your seeders get in the way, this guide on migrate:fresh --seed failing to seed into MySQL covers that.

1. Detach the empty tablespace:

ALTER TABLE orders DISCARD TABLESPACE;

1. Copy your saved orders.ibd back into C:\xampp\mysql\data\shop_db\.
2. Attach it:

ALTER TABLE orders IMPORT TABLESPACE;

You may get a warning about a missing .cfg file. That's expected when the table wasn't exported with FLUSH TABLES ... FOR EXPORT. A "schema mismatch" error means the structure differs from the original, often in a column type or ROW_FORMAT. Fix the CREATE TABLE and try again.

Repeat for each table. Then run SELECT COUNT(*) FROM orders; to confirm the rows came back.

Cause 2: #1932 on phpmyadmin.pma__ tables

How to confirm it

The message names something like phpmyadmin.pma__userconfig or phpmyadmin.pma__tracking, and it often shows up right after logging in. Your own data is fine. The broken tables belong to phpMyAdmin's configuration storage.

Fix: rebuild the phpmyadmin database

phpMyAdmin ships the SQL file that creates these tables. Drop the broken database and import the file again:

C:\xampp\mysql\bin\mysql.exe -u root -p -e "DROP DATABASE IF EXISTS phpmyadmin;"
C:\xampp\mysql\bin\mysql.exe -u root -p < C:\xampp\phpMyAdmin\sql\create_tables.sql

If root has no password (the XAMPP default), press Enter at the prompt. You'll lose saved phpMyAdmin settings and bookmarks, which is a fair trade. If phpMyAdmin then complains that the control user connection failed, check the controluser and controlpass values in C:\xampp\phpMyAdmin\config.inc.php.

Cause 3: tables doesn't exist in engine after an upgrade or crash

How to confirm it

The failing tables are in the mysql database (for example mysql.innodb_index_stats), or the problem started right after you upgraded XAMPP or after MySQL crashed.

Fix: run the upgrade tool

C:\xampp\mysql\bin\mysql_upgrade.exe -u root -p

It checks and repairs the system tables for the version you're running. Restart MySQL afterwards. On Linux installs, also check file ownership, because InnoDB can't open files it isn't allowed to read:

sudo chown -R mysql:mysql /var/lib/mysql

If nothing worked: gather the right logs

Collect these before asking anyone for help:

SELECT VERSION();
SHOW VARIABLES LIKE 'innodb_file_per_table';
SHOW VARIABLES LIKE 'datadir';

Also grab the last 50 lines of C:\xampp\mysql\data\mysql_error.log and a directory listing of the affected database folder, so someone can see whether the .ibd files exist and how large they are.

If MySQL won't stay up long enough to export anything, add this under [mysqld] in C:\xampp\mysql\bin\my.ini:

innodb_force_recovery = 1

Start MySQL, dump what you can with mysqldump, then remove the line. Raise it one step at a time only if 1 doesn't work. Higher values can lose data, and the server shouldn't run normally with this setting on. If InnoDB internals start to feel unfamiliar, this post on finding a query from its query_id in InnoDB shows how to read some of the same information_schema data.

If your data is in a state you can't afford to lose, you can contact HeadsNTail for a hands-on look.

FAQ

Can I just delete the table and create it again?

Yes, if you don't need the data. Stop MySQL, delete the table's .frm and .ibd files from the database folder, start MySQL, and recreate the table. If you do need the data, use the .ibd import method above first.

Why does phpMyAdmin show the table if it doesn't exist?

phpMyAdmin lists what it finds in the database folder. InnoDB only opens tables registered in its data dictionary. When the two disagree, you see the table in the list but can't open it.

Will deleting ibdata1 fix MySQL in XAMPP?

It might get the server running, but every InnoDB table will then throw #1932, because their registration lived in that file. Back it up before trying any fix that replaces or deletes it.

Does this error happen with MyISAM tables?

No. MyISAM tables are self-contained in their own files, so copying the folder is enough. Error #1932 is specific to InnoDB.

Next time you move an XAMPP install, export with mysqldump instead of copying folders, and you won't see mysql phpmyadmin: error #1932 - table doesn't exist in engine again.