From what I’ve gathered in most cases for MySQL databases, usually, a php.ini file within the site directory has a line of code for “Max_input_vars” that can increase the limit from 1000 fields (initially) to whatever else you set it.
This error apparently shows once a table goes over 1000 fields (rows x columns). The means to fix it would be to set the Max_input_vars higher to accommodate. In some cases, that’s only accessible from the host’s dev team.
DIdn’t receive this message before, when there were even more columns in my table. Host has changed that ini-file in the last 2 weeks or so?
No developers haven’t changed anything and we won’t change anything, there must be a solution surely if it was working fine previous.
Any ideas? Even unable to delete a row (I can if I use a query, but not by just clicking a button)…
A solution is here. The setting max_input_vars cannot be set at run-time with ini_set, but you can reset it in an .htaccess file:
php_value max_input_vars 2000
I’ve just tested that, and it works on 000webhost.com. However, I would consider that a temporary fix - the warning means you are using more than 1000 fields on a form, which is an enormous number. If this is affecting phpMyAdmin, I wonder if it is using a large number of hidden <input> fields in the background - check the HTML source?
More than 1000 fields on a HTML-form?! 2 hidden input fields, that’s it. The problem isn’t inserting with an html-form, the problem is in phpmyadmin. I have 47 columns in that one table, a few dates and int, a lot more varchars (50-100), and 1 mediumtext: is that so ‘abnormal’? Never had any trouble with it.
So actually you’re saying: make another table and store half of the data in that one and it will be solved?
Yes, that is the cause of the error you are getting.
I don’t know phpMyAdmin well, especially not from a open-source development perspective. Perhaps some elements are created on a form submit or something? Without a reproducible test case in front of me, I can only speculate.
phpMyAdmin uses HTML forms and PHP, so it could conceivably be affected by this PHP issue. It isn’t related to inserting (in a database sense) anyway - it is to do with the how PHP creates variables in a POST operation (e.g. in a form submission).
Definitely not - a database structure should not be dictated by a bug in a development tool. The bug needs to be found and resolved, or the tool needs to be changed.
As I say, I will need a reproducible test case to help further. I suggest you create a database export that someone could load into their own database in order to examine the issue further. Please add detailed, step-by-step bug reproduction instructions also.
Looks like several folks have had issues with phpMyAdmin with this setting.
If I delete some columns the message disappears (unless I want to see 50 instead of 25 rows in phpmyadmin).
But even with fewer columns I still can not use ‘edit, copy, delete’ (the options at the left of every row in that specific table). Inserting a new row works, and using a sql-query to delete a row works as well.
Any ideas?
Does it tell you there is no unique column? 
No, the unique column is the autocrement one (unless I misunderstand you).
It only/still shows the second screenshot on top of this thread.