Skip to content
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

PHP MySQL version differs from MySQ server version #8877

Closed
pma-import opened this issue Aug 23, 2007 · 39 comments
Closed

PHP MySQL version differs from MySQ server version #8877

pma-import opened this issue Aug 23, 2007 · 39 comments
Labels
Bug A problem or regression with an existing feature

Comments

@pma-import
Copy link

Dear,

I’m new in using phpMyAdmin 2.11.0 and I’m still getting the following error on main page:

Your PHP MySQL library version 5.0.45 differs from your MySQL server version 3.23.32. This may cause unpredictable behavior.

I saw in ChangeLog, that in 2.11.0 phpMyAdmin also checks for differences between MySQL library and MySQL server. Although my PHP MySQL library is really version 5.0.45, my MySQL server is 5.0.45 too. I never used MySQL3.

Note:
When I installed the new version of phpMyAdmin, I only rebuilt phpmyadmin database ( database for pma controluser ), but everything seems to be built correctly – I also checked the original manual on phpMyAdmin wiki.

I am running MySQL 5.0.45 and Apache 2.2.4 with PHP 5.2.3 ( without any Zend Optimizer ) installed on Windows XP.

Thanks for help,

Lukáš Chmela


- Original URL: https://sourceforge.net/p/phpmyadmin/bugs/2513/
- Original author: kyselejsyrecek
- Found in version: 2.11.0

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

Please attach here a screenshot of the main phpMyAdmin page (the one when you click on the Home icon).


- Original author: lem9

@pma-import
Copy link
Author

- assigned_to: nobody —> lem9
- status: open —> pending


- Original author: lem9

@pma-import
Copy link
Author

Screenshot of phpMyAdmin-2.11.0 in English language, showing the error message on main page


- Original author: kyselejsyrecek
- Attachment: http://sourceforge.net/p/phpmyadmin/bugs/_discuss/thread/f6bf6cde/32ee/attachment/phpMyAdmin-2.11.0.png

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

OK, here’s some screenshot.
File Added: phpMyAdmin-2.11.0.png


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

- status: pending —> open


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

Ok, PMA displays this version number when there is no output for
SELECT VERSION();

(in libraries/database_interface.lib.php)

Please try this command in the SQL query windows and post the results. I am running 5.0.45 here and SELECT VERSION() reports 5.0.45.


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

OK, I thought something like this – that the 3.23.32 is default value for MySQL server version.

I tried this in original MySQL client console application and then I got this result:

5.0.45-community-nt

When I tried this in the phpMyAdmin-2.11.0, I got the same result.

Maybe the problem is in the “-community-nt” suffix.
Also thanks for your info about where phpMyAdmin gets the version info.


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

I looked into the source code of the file, you entered and then I saw, there cannot be any problem in the version suffix. Probably on the line “PMA_DBI_fetch_value(‘SELECT VERSION()’, 0, 0, $link, PMA_DBI_QUERY_STORE);” – PMA_DBI_fetch_value() could require other parameters or I don’t know what else.. I don’t know, where’s the function defined.


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

The PMA_MYSQL_STR_VERSION takes any suffix like “-community-nt” into account, there is no problem here. Please trace in the PMA_DBI_postConnect() function to see what happens. I guess that at this point, SELECT VERSION() is failing for an unknown reason on your machine.


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

Sorry, I don’t know, what you had in mind. I’m just PHP coder and I don’t know PMA’s core.
I only found out that the line I posted returns nothing.

If you want me to find out more about this, please tell me where I can find the PMA_DBI_fetch_value() function.

Thank you.


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

What I had in mind was, first, to add one line like this:
function PMA_DBI_postConnect($link, $is_controluser = false)
{
if (!defined(‘PMA_MYSQL_INT_VERSION’)) {
$mysql_version = PMA_DBI_fetch_value(
SELECT VERSION()’, 0, 0, $link, PMA_DBI_QUERY_STORE);
if ($mysql_version) {
$match = explode(‘.’, $mysql_version);
define(‘PMA_MYSQL_INT_VERSION’,
(int) sprintf(‘%d%02d%02d’, $match0, $match1,
intval($match2)));
define(‘PMA_MYSQL_STR_VERSION’, $mysql_version);
unset($mysql_version, $match);
} else {
echo ‘trace here’;
define(‘PMA_MYSQL_INT_VERSION’, 32332);
define(‘PMA_MYSQL_STR_VERSION’, ‘3.23.32’);
}

  1. }

PMA_DBI_fetch_value() is in the same script.


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

Aha..

I tried to use mysql_error() with this result:
Access denied for user ’pma’@’localhost’ (using password: YES)

But I didn’t see any warning message about the user pma cannot be logged on – like in other versions of PMA.
I think, phpMyAdmin should warn about this, if pma user is so important.

The problem is fixed now.
I used one unsafe character in password (§).

Maybe some warning about unsafe characters in user’s password will be useful to.

The thread is closed now.

Thank you very much for help,
Lukáš Chmela


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

- status: open —> closed


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

I reopen: this needs further investigation.


- Original author: lem9

@pma-import
Copy link
Author

- assigned_to: lem9 —> nobody
- status: closed —> open


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1383652
Originator: NO

I got no problems using “test§” as a password neither at normal user login nor in config.inc.php:
$cfg[‘Servers’][$i][‘controlpass’] = ‘test§’;

maybe it’s a matter of the browser default characterset and a different one used by the editor used to modify the config settings?


- Original author: windkiel

@pma-import
Copy link
Author

Logged In: YES
user_id=1790839
Originator: YES

lem9: ok

windkiel: I set the password also in the MySQL client application and the result was “0 affected rows”. My MySQL server uses UTF-8 and phpMyAdmin should be configured for UTF-8 as well. But I see, my configuration file was encoded by ANSI charset. When I encoded it with UTF-8, it fixed the problem. I never crossed this mind.

It could be in some FAQ.


- Original author: kyselejsyrecek

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

Cannot reproduce this problem (bad MySQL version detected) with a wrong controlpass. I think your case is too specific to even go into a FAQ but I am glad you found the problem.


- Original author: lem9

@pma-import
Copy link
Author

- assigned_to: nobody —> lem9
- status: open —> pending-invalid


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=454150
Originator: NO

I believe this message was a bad idea in the first place and should be removed, or made optional.

My guess is that most users of phpMyAdmin have a different client version from the server version, and they should not be expected to re-link apache / php every time they upgrade their server.

Additionally, we use phpMyAdmin to manage all the MySQL databases company wide, and there are different versions.

If anything, this warning should be small – not a big red box. Please fix.


- Original author: jmpz

@pma-import
Copy link
Author

Logged In: YES
user_id=1882904
Originator: NO

Exact same problem on my system with PHP 5.2.3 on Redhat Linux 4


- Original author: gifttree

@pma-import
Copy link
Author

Logged In: YES
user_id=1383652
Originator: NO

from irc (same issue, client=4.1 and server 5.x):
<asdzxc> my customers are keeps e-mailing me about ‘very serious errors in their accounts…’ :/
-8<-
<asdzxc> Debian Sarge

an option in config.inc.php would be helpful indeed.
just my 2cent.


- Original author: windkiel

@pma-import
Copy link
Author

- status: pending-invalid —> open-invalid


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

Well, I don’t believe in this kind of configuration option. Almost everyone will turn the message off. We are just applying MySQL’s advice:
http://dev.mysql.com/downloads/connector/php/
“We recommend to use the MySQL Client API version that matches the
MySQL Server version.”

In 2.11.1, we don’t display the message if only the Z part of X.Y.Z is different.


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1383652
Originator: NO

hmm,
1st) Connector/PHP is for windoze, <asdzxc> (Debian Sarge) said he would have to recompile agains mysql 5.
2nd) some people have to manage various remote mysql servers with different versions – not everybody is willing or able to patch main.php everytime.


- Original author: windkiel

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

1) I don’t think that the protocol restrictions they are describing are specific to Windows. Anyway, we got many problem reports on the forum about non-matching MySQL client lib. I wish I had collected all those to have more specific cases.

2) I understand, but on the other hand, those people might have problems with their non-matching client lib, so why not warn them?

There is this specific problem:
http://dev.mysql.com/doc/refman/5.0/en/old-client.html
http://forge.mysql.com/wiki/PHP_FAQ
so even if we change the logic of when this message should be displayed, the pre-4.1 situation is an absolute minimum.


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1383652
Originator: NO

ok
1) what I meant is: on win it’s relative easy to fix by downloading and installing the mysql “connector” (which is almost always behind the actual shipped mysql version btw.) or copying the latest libmysql.dll from mysql/bin into a prominent position in the search path (dunno how it works exactly on linux).

2) if the warning is active by default it’s in the responsibility of the user or the admin of the site when they turn it off.

3.) that’s when the warning makes sense, but not if I connect, e.g., with a 5.0.x client to a 4.1.x server.

YMMV


- Original author: windkiel

@pma-import
Copy link
Author

Logged In: YES
user_id=326580
Originator: NO

“but not if I connect, e.g., with a 5.0.x client to a 4.1.x server.”

why? do have any other information than i?


- Original author: cybot_tm

@pma-import
Copy link
Author

Logged In: YES
user_id=326580
Originator: NO

from http://dev.mysql.com/downloads/connector/php/

“Can I query any server older than 4.1.21/5.0.27 with the binaries provided?

You might be able to do that, but we do not recommend it. You should use the mysql and mysqli extensions that we offer for download only to access the MySQL Server 4.1.21 and 5.0.27."

they do not recommend connecting to older versions, they do not write 4.1.x or 5.0.x they writing explicitly 4.1.21 and 5.0.27

but possible we could make the “red alert box” just a “yellow info box” and tweak the message displayed

@jmpz:

“My guess is that most users of phpMyAdmin have a different client version
from the server version”

i don’t think so …

“and they should not be expected to re-link apache / php every time they upgrade their server.”

of course they should!
this is the only way how security fixes in MySQL will also apply to this linked applications (if the client lib is affected!).

“Additionally, we use phpMyAdmin to manage all the MySQL databases company wide, and there are different versions.”

this makes no difference


- Original author: cybot_tm

@pma-import
Copy link
Author

- milestone: —> 2.11.0


- Original author: cybot_tm

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

CSS class changed from warning to notice (red to yellow).

  1. Sebastian:

“Additionally, we use phpMyAdmin to manage all the MySQL databases company
wide, and there are different versions.”

  1. this makes no difference

well I think it does make a difference since I might be using one Apache/PHP on machine A, linked to lib 5.0.45 for MySQL on machine A, to manage also MySQL 4.1.x on machine B. Of course this is not recommended… but I think that since the message in PMA 2.11.1 does not display if the MySQL X.Y.Z version only differs for Z, it will help.


- Original author: lem9

@pma-import
Copy link
Author

- status: open-invalid —> open-fixed


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=210714
Originator: NO

Juergen,
assuming we would have a config option for this, I am pretty sure the distros would turn it off by default, and our message (and MySQL AB’s message) would not reach users (and mostly sysadmins).


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=326580
Originator: NO

  1. Marc:

“Additionally, we use phpMyAdmin to manage all the MySQL databases
company
wide, and there are different versions.”

  1. this makes no difference

“well I think it does make a difference since I might be using one
Apache/PHP on machine A, linked to lib 5.0.45 for MySQL on machine A, to
manage also MySQL 4.1.x on machine B. Of course this is not recommended…
but I think that since the message in PMA 2.11.1 does not display if the

  1. MySQL X.Y.Z version only differs for Z, it will help."

i understand and know and have this problem too, but:
this makes no difference for the problem with different versions – it does not more or less apply to remote servers than to local servers … and even it could make the problem more worse as more parts are involved (TCP/IP or networking in general)


- Original author: cybot_tm

@pma-import
Copy link
Author

- status: open-fixed —> pending-fixed


- Original author: lem9

@pma-import
Copy link
Author

Logged In: YES
user_id=1598099
Originator: NO

Hi,

maybe it will be usefull somebody:

I’ve checked that no matter of versions PMA (2.10 or 2.11) if you have broken config.inc.php – specialy in SERVER DEFINITION SECTION – and if server defined before is dead – var $link in that function postConnect will be null.

So when I deleted all other defined servers except my – my CORRECT version (5.0.45-log) and all other (3.23+) SHOWS AND WORKING :D

So all you have to do – check your config.inc.php

My Serv:
Linux 2.6.21.5-SMP i686 Slack12
Apache/2.2.4 (Unix) DAV/2 PHP/5.2.4
MySQL 5.0.45-log
phpMyAdmin 2.11.1


- Original author: fungms

@pma-import
Copy link
Author

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).


- Original author: sf-robot

@pma-import
Copy link
Author

- status: pending-fixed —> closed-fixed


- Original author: sf-robot

@pma-import
Copy link
Author

  • Status: closed-fixed --> fixed

  • Original author: nijel

@pma-import pma-import added the Bug A problem or regression with an existing feature label Jul 24, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug A problem or regression with an existing feature
Projects
None yet
Development

No branches or pull requests

3 participants
@lem9 @pma-import and others