To connect to a MySQL server, PHP needs the mysql extension (the mysqli extension is recommended for MySQL 4.1+), which is a set of MySQL functions. This extension may be compiled as a part of the PHP server. This error implies that no other PHP script can make connections to a MySQL server.

The required extension is contained in a file that can be named mysql.so or mysqli.so on Linux or UNIX, or mysql.dll (maybe mysqli.dll) on Windows. If our PHP server comes from a software package, we can find and install another software package probably called php-mysql or php-mysqli. (The name is distribution dependent.) Otherwise, we can compile our own PHP server with the appropriate extension, as explained in the PHP documentation.

This message indicates that the MySQL server is not running, or cannot be reached from the web server. It can also be caused by a socket (Linux/UNIX) or named pipe (Windows) configuration problem.

This message means that the socket configured in php.ini (an example of which is given below) does not correspond to the socket of the running MySQL server:

mysql.default_socket = /tmp/mysql.sock

As a result, PHP cannot reach MySQL. We can change it to:

mysql.default_socket = /var/lib/mysql/mysql.sock

However, to be sure, we must find the exact location of this socket.

This is a problem similar to the one indicated above, but on Windows. It can be solved by adjusting mysql.default_socket to the correct named pipe used to connect locally to a MySQL server. For example:

mysql.default_socket = MySQL

This error can be solved when we understand the relevant login parameters.

We cannot use the web server security mechanism based on a .htaccess file and the http authentication in config.inc.php together. As a workaround, use cookie as the authentication type, instead of http.

The host parameter in config.inc.php must match the host defined in the user access privileges. Sometimes, a system administrator may create an account authorizing user bill and host localhost. If we try to use the 127.0.0.1 host in config.inc.php, it will be rejected by MySQL even though it points to the same machine. The same problem can occur if we try the real name of the machine (mysql.domain.com) and the definition has been made for localhost.

If the message ends with using password: NO, it means that we are not transmitting a password, and MySQL is rejecting this login attempt. The password value may not have been set in config.inc.php.

A password has been transmitted, but the host/username/password combination has been rejected by MySQL.

phpMyAdmin wants to promote security; therefore the $cfg['Servers'][$i]['AllowNoPassword'] directive is set to false, blocking attempts to log in with any account but no password. We have to set this to true in order to accomplish an initial login, in the case where our account is really without a password.

This problem is caused by some characters (such as blank lines or spaces) being present in config.inc.php either before the<?php tag at the beginning, or after the ?> tag at the end. We should remove these with an editor that supports .php files (as discussed in Chapter 1,

In the navigation panel, we click on the database name. In the main panel, we select the name of the table for which there is an error (using the relevant checkbox). We then choose Repair from the lower drop-down list. More details are available in Chapter 9,

MySQL requires that an index set on a BLOB column be limited in size. The simple index creation technique available when creating a column does not permit the size to be specified. Therefore, we need to create the column without an index. We then come back to the Structure page, and use the Create an index dialog to choose the BLOB column and then set a size for the index.

This is a permission problem. Internet Information Server (IIS) must be able to read our scripts. As the server is running under the user IUSR_machinename, we have to carry out the following steps:

This happens when the $cfg['PmaAbsoluteUri'] parameter in config.inc.php is not set properly. Chapter 1, Getting Started with phpMyAdmin, explains how to take care of this parameter.

By default, phpMyAdmin uses output buffering and compression techniques to speed up the transmission of results to the browser. These techniques can interfere with other components of the web server, causing display problems. We can set $cfg['OBGzip'] to FALSE in config.inc.php. This should solve the problem.

No privileges appears next to the Create database dialog on the home page, if phpMyAdmin detects that the account used to log in does not have the permissions necessary to create a database. This situation occurs frequently on hosted servers, where the system administrator prefers to create one database for each customer.

If we are not on a hosted server, this message simply reflects the fact that we have neither the global CREATE privilege nor any CREATE privilege on a wildcard database specification.

Usually, these problems indicate that we have hit a limit during the transfer. Chapter 8, Searching Data, explains these limits and the recommended course of action. As a last resort, we might have to split our large text files. (Search the Internet for file splitters.)

The MySQL manual explains the general solution at http://www.mysql.com/doc/en/Resetting_permissions.html.

The solution involves stopping the MySQL server and restarting it with the special option skip grant tables (which basically starts the server without security). The way to stop and restart the server depends on the server platform used. We can then connect to the server from phpMyAdmin as a superuser (like root) with any password. The next step is to change the root's password (see Chapter 19, Administrating the MySQL Server with phpMyAdmin). We can then stop the MySQL server and restart it using normal procedures. (Security will become active again.)

Here is a curious symptom. When we try to create a table containing, for example, one field named FIELD1 of type VARCHAR(15), it looks like phpMyAdmin has sent a command to create two identical fields named FIELD1. The problem is not caused by phpMyAdmin, but by the environment. In this case, the Apache web server seems well-configured to run PHP scripts when in fact it is not. However, this bug appears only for some scripts.

The problem occurs when two different (and conflicting) sets of directives are used in the Apache configuration file. The first set of directives are:

SetOutputFilter PHP
SetInputFilter PHP

The second one is:

AddType application/x-httpd-php .php

These sets of directives may be in two different Apache configuration files, and hence, difficult to notice. The recommended way is to use AddType. Using this, we just need to comment out the other lines (as shown in the following snippet), and then restart Apache:

#SetOutputFilter PHP
#SetInputFilter PHP

This problem occurs when we try to start phpMyAdmin with a URL other than the one set in $cfg['PmaAbsoluteUri']. For example, a server may have more than one name, or we may try to use the IP address instead of the name.

For a more efficient column definition, MySQL itself sometimes decides to change the column type and size. This happens mostly with CHAR and VARCHAR type fields.

This problem occurs mostly after an upgrade to MySQL 4. The automatic server upgrade procedure gives the global privileges CREATE TEMPORARY TABLES, SHOW DATABASES, and LOCK TABLES to all users. These privileges also enable users to see the names of all of the databases (but not their tables) until we upgrade the GRANT tables privilege as described in the MySQL manual. If the users do not need these privileges, we can revoke the privileges. The users will then see only those databases to which they have access rights.

This is normal if we have defined a column of type TINYINT, as 127 is the maximum value for this column type. Similar problems may arise with other numeric column types. Changing the type to INT expands the available range of values.