Database Errors

Thanks for your tip, @iamshubhamsp

Before I saw your latest post, I tried replacing the entire XAMPP > MySQL > data folder with a backup that I had. I still received the Error establishing a database connection message. Then, I tried replacing the same data folder with a version from an even older backup. Same error occurs. Again, I had been working on my site for a long time before and the connection to the database was not an issue. If a backup is not restoring the connection and the site, what is causing this issue all of a sudden?

I never really moved/migrated the site anywhere. So far it’s only been on my localhost hard drive connected to my workstation.

In any case, I’ll try the other steps you outlined in your message.

• This reply was modified 1 year, 1 month ago by themavo.

Well, @catacaustic, as it stands, I’ve rather soured on MySQL because it’s so unreliable. So often the overall MySQL app doesn’t even start at all in XAMPP. Whenever that happens, I have to replace most of the files in the mysql > data folder with versions in the mysql > backup.

Now there’s suddenly no connection at all to the WP database. What do I need to do now to have this site back on track again? There must be something…

Hi again, @iamshubhamsp . I’m just following-up.

I enabled the WordPress repair of wp-config.php, following your earlier directions.

After the process of attempting the repair was done, WordPress displayed a log that listed a number of tables as being “okay.” For example:

The wp_users table is okay.
The wp_usermeta table is okay.
The wp_posts table is okay.
etc.

But the wp_options table was listed as being “not okay.” WordPress couldn’t repair it, stating that it “doesn’t exist in engine” (as I noted earlier in this thread).

But then I used Windows File Explorer to locate all of the files related to the tables WordPress accessed for this repair process.

The files for each table listed as okay were there…But so were the files for wp_options, which WordPress claims “doesn’t exist.” They all seem to be there in their correct locations. (It appears each table has two files: name.frm and name.ibd.)

Then, I tried to access the tables using phpMyAdmin.

There, under the affected database, all the tables WordPress checked are listed, including wp_options. But, unlike the other tables, the status of wp_options reads “in use.” It’s the only table which has that status.

When I click on wp_options from within phpMyAdmin, I receive an error message that reads “#1932 – Table ‘themavo.wp_options’ doesn’t exist in engine.”

But, according to File Explorer, it actually does exist along with all the other tables. I’m not sure what could be causing it to be regarded as “nonexistent” in phpMyAdmin and WordPress. Maybe that table’s files are somehow corrupt…

Thanks for your response, @iamshubhamsp .

No, as far as I know, XAMPP did not crash while I was working on the website. Not when I first started to work on it, nor during the process of designing it.

I did run into several episodes where I the MySQL app did not immediately start from within the XAMPP control panel. That still happens on occasion, but I found a reliable solution for whenever that happens:

https://stackoverflow.com/questions/78796430/how-to-completely-restore-a-wordpress-site-from-a-manual-backup

So, as far as I can see, I’ve managed to keep MySQL and XAMPP running as far as .

But, concerning the wp-options table: I’ve made copies of the entire site, on several different dates and I still have all those copies. I tried replacing the most recent files containing the wp-options table with versions from those older copies I made. The site was working well when I made those copies. But now the site still treats even the older versions as if they’re corrupted or missing.

Why are even the older copies not working?