Broadly speaking, as the error says, you are not connecting to your database. So, check to make sure everything is "plugged in" properly.
Things to check:
- file exists
- triple check you are using the correct database info for your current server/environment (host, username, password, and database name)
- file has ...
You are hitting the limits of InnoDB. It might work to change your table to the MyISAM engine (backup before changing this), as the limits of MyISAM are larger compared to InnoDB.
Note that this can cause an performance hit as table locking acts different on MyISAM.
You can also replace all VARCHAR fields (with more than 10 characters) with a TEXT field. ...
* Error Reporting
* PHP and database errors are normally displayed dynamically based
* on the authorization level of each user accessing your site.
* This variable allows the error ...
You should never have to reinstall addons locally if you are pulling files/DB from production properly. If you are having this problem, the issue is most likely related to how you are doing the migration.
I'd suggest your errors are caused by your exported SQL not including DROP TABLE and you aren't manually dropping the tables in the DB before your import. ...
I think it will be enough to delete field record in exp_channel_fields table.
Go to EE CP SQL manager (CP Home > Tools > Data > SQL Manager > Database Query Form) or phpMyAdmin or any other mysql manager:
DELETE FROM exp_channel_fields where field_id = 21;
if you want to be sure that any pieces of your grid field was removed, execute query bellow line-by-...
I am experiencing the same problem where it seems to happen when "Is field searchable?" is enabled within the field settings containing the Matrix field-type (not sure why??!)...
I found a solution by changing line 7595 from
$select .= ', field_id_'.$fields[$key].' AS `'.$key.'`';
$select .= ', cd.field_id_'.$fields[$key].' AS `'.$key.'`';
For this particular quandary, this worked:
Add this line to the top of the SQL file:
SET FOREIGN_KEY_CHECKS = 0;
If you see this problem and the above solution doesn't work, check this thread as well:
This looks like a bug in Store and will be fixed in the next version.
In the meantime, if you need a fix you can open third_party/store/src/Store/Module.php and around line 773 look for this:
$this->queryAndOrParam($query, 'order_status', ee()->TMPL->fetch_param('order_status'));
Change it to this:
I know this is a bit old, but I had this issue on a site recently. Couldn't create or update channels or fields. Turns out it was the Solspace Calendar module. Uninstalling it fixed the error, bit obviously deleted all the content.
This ended up being simple. For my instance, the MySQL module wasn't installed for PHP. Once it was added it worked as expected... My issue ended up being the fact that the error was completely non-descript.
A couple things. Usually get the the ERR_CONTENT_DECODING_FAILED error when there are PHP errors/notices breaking the gzip output. You can turn off Gzip Output in the Output and Debugging preferences. This will allow you to see what the errors are on the front end.
The errors are most likely strict and deprecation notices. If so, you can disable these error ...
The developer gave a solution here: https://devot-ee.com/add-ons/support/mustash/viewthread/15161
Change the following code on line line 664 in mcp.mustash.php:
'group_id' => $group[$index],
'group_id' => ($group[$index] == "NULL" ? NULL : $group[$index]),
Solution posted in question:
Apparently there is an undocumented bug in EE -
if your database password contains a percent symbol EE will fail to finish installation and configuration, thereby leaving you with a 'unable to connect to database' error on the second screen of install.
Here's the deal. I had several 'Select Dropdown' fields and on one of those fields a radio button was not selected:
Populate the menu manually
Populate the menu from another channel field
If one of them is not selected it throws this error. Personally I think this is a bug, but at least there is a solution.
So the config file for this site had:
$db['expressionengine']['swap_pre'] = "pfra_";
when it should in fact have been
$db['expressionengine']['swap_pre'] = "exp_";
even although the db tables are all set with a prefix of pfra_
Sometimes these errors happen because of the connection or application used in exporting the db. I'd recommend using Sequel Pro to export the db with DROP tables syntax and gzipped. If you still see the alert/error, then there's really something wrong.
Sounds like an odd error to run into. I'd say it was one off with the key index for that table and you will be fine from now on.
If you are concerned however, you can rebuild the table index:
To rebuild a table by dumping and reloading it, use mysqldump to
create a dump file and mysql to reload the file:
shell> mysqldump --all-databases > dump.sql