New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQL duplicate entry error trying to INSERT in designer_settings table #11727
Comments
Actually it should and was meant to UPDATE only and the code was originally written to do update. Or may be try deleting the row for the user manually first and then open up designer, change some settings (so that a row is inserted) into the Also, could anyone confirm if they can also reproduce this issue ? |
Cannot reproduce. To debug this, we need some tracing from you. In libraries/pmd_common.php, function PMA_saveDesignerSetting(), the decision to UPDATE or INSERT is based on the results of a SELECT. Please tell us the content of $orig_data_query and $orig_data. |
$orig_data_query =
$orig_data = It seems that $orig_data is empty, so it doesn't go to the UPDATE query. I noticed that when printing $GLOBALS['dbi'] and $GLOBALS['controllink'] are also empty. Not sure if that is the issue. |
Just a few questions.
|
|
If that is so, then I am not sure what exactly might be the issue. |
@jesucarr The fact that $GLOBALS['dbi'] is empty is a Bad Thing. When I trigger this code by clicking on "Toggle relation lines" in the Designer, $GLOBALS['dbi'] is not empty at this point. Please tell us if the error message appears when you click on the Designer menu tab or when you try some action in the Designer (which one?) |
The error message appears as soon as I go to the Designer page (without doing any action), and also when I do any action, for example clicking in "Toggle relation lines". $GLOBALS['dbi'] is empty in both situations. What I'm doing to see it is comment out the two PMA_queryAsControlUser calls and add a |
Ok, keep us posted. Meanwhile, are you sure you did not install phpMyAdmin over a previous installation? |
Hi @jesucarr, I realised that $GLOBALS['dbi'] should not be concatenated with string as it is an object not a string. I think if you instead do My output (
|
That's right @devenbansod it wasn't empty. I get the same as you for $GLOBALS['dbi'], but $orig_data[0] is empty. |
After $orig_data is set, try this:
|
that's empty. $GLOBALS['controllink'] is empty too. |
Did you log in (assuming your auth_type is 'cookie') with your control user? |
auth_type is 'cookie', but I'm not logging in with the control user |
What does "mypmacontroluser" mean then? |
Sorry that was supposed to be "myuser" |
Okay. So just confirming. You have a user named 'myuser' and have a row with 'myuser' already in the Any corrections ? |
Yes that's it |
@jesucarr Did you get phpMyAdmin from http://phpmyadmin.net ? Could you attach here your config.inc.php, obfuscating sensitive info? |
I installed it in Centos 7 using yum, from the remi-test repository (4.5.2-1.el7.remi). Here is the config.inc.php
|
Just to be sure, the error message you get (duplicate entry) does not show 'mycontroluser' but 'myuser', correct? |
correct |
Just tested that if I don't give access permissions to the user serving the app to the /etc/phpMyAdmin directory, it uses the default config and the Designer works. However when the app has access to that folder the Designer fails as described also when using the default config.inc.php in that folder (just adding the right controluser/password). |
@jesucarr Isn't this a CentOS issue then? |
What do you mean? If I don't give access to the folder it is supposed to not be able to access the file, so CentOS is working as expected. |
Do you still consider this to be a phpMyAdmin bug? I don't know what you mean by "give access permissions to the user serving the app". IMO giving proper permissions at the web server level is out of scope for phpMyAdmin. |
Hi, @jesucarr :
If the above behavior describes your problem exactly, then I would agree with Marc that it should not be a phpMyAdmin bug since it is dealing with the permissions on the webserver's app. But please correct me if I explained the behavior incorrectly somewhere. |
Sorry guys I think I confused you rather than help to debug. The point is that if it doesn't load any config.inc.php it works, but if it loads a config.inc.php (even the default one) it gets the error. Obviously I want to be able to load my custom config.inc.php. |
@jesucarr Please confirm whether or not Deven correctly summarized your problem. The reason we are asking, is to determine if phpMyAdmin has a bug affecting you, or if it's a permission problem at the web server's level (which we are not responsible of). |
I'm not talking about any weird permissions configuration. I just wanted to test if it was an issue with my config.inc.php. How am I supposed to load my custom config.inc.php if I don't give it read permissions to the webserver running phpMyAdmin? |
@jesucarr To help me help you, please reply by just Yes or No: do you consider this to be a phpMyAdmin bug? Before replying, note that placing config.inc.php under /etc/phpMyAdmin is not the decision of the phpMyAdmin project, but of CentOS. |
I suppose it is a phpMyAdmin bug, unless the the config.inc.php need to be in the top level directory directory being served by the webserver in order for the Designer to work? Would that explain why $orig_data[0] is empty? |
I just made a test: moving config.inc.php to another directory (that the web server is allowed to read) and define this other directory in libraries/vendor_config.php like this:
With that in place, I have no problem using the Designer. Disclaimer: I'm not using CentOS but Debian 8. |
Yes, the package defines it like this:
So it should work too. The real question is: what can cause $orig_data[0] and $GLOBALS['controllink'] to be empty? |
Please do some more tracing. In librairies/common.inc.php there are 3 places where $controllink can be initialized, so we need to know where it's initialized and whether it's empty or not at this point. |
it is initialized in line 974, and the content is
|
Thanks. This is the first hint we get (apart from your CentOS comment) that this is happening on MariaDB 5.5.44. |
I compared the results of print_r with mine at initialization time, and they are similar (but mine is to MySQL 5.7.8). I did a print_r further in the logic:
and get similar valid info for the control link. Can you confirm that you still don't get this info at this point? |
I get:
|
So, $GLOBALS['controllink'] is no longer empty? (You said previously that it was empty at this point). |
Sorry I think I wasn't debugging properly, error_log works better. The one empty is $orig_data after the fetch at line 730, that's why it goes to the INSERT instead of the UPDATE. If I do |
Any chance you could install phpMyAdmin downloaded from http://phpmyadmin.net? |
I get the same error when installing phpMyAdmin from http://phpmyadmin.net |
@jesucarr : Does the change suggested in this comment (#11808 (comment)) work for you too ? |
Yes that seems to work! |
Signed-off-by: Deven Bansod <devenbansod.bits@gmail.com>
Thanks @jesucarr for all the tests and feedback help. |
I'm getting this error when going to the Designer page:
#1062 - Duplicate entry 'myuser' for key 'PRIMARY'
The SQL that is trying to execute is:
In the table settings there is already one row with that username, and the setting {"snap_to_grid":"off"}
As the table has the username as primary key, I guess the query should try to UPDATE and add the new setting value, instead of trying to INSERT.
When I try to add settings to the pma__userconfig table, it works as expected.
I'm using version 4.5.2 and PHP 5.6.16
The text was updated successfully, but these errors were encountered: