2006 MySQL server has gone away trying to install on Network Solutions

Same issue with Leopard Server 10.5.8 Apache/2.2.14 PHP 5.2.12

Occurs with both alpha3 and alpha4.

Alpha3 gives: Fatal error: Class 'MergeQuery' not found in xxx /includes/database/database.inc on line 751

Alpha4 gives: Fatal error: Class 'DeleteQuery_mysql' not found in xxx /includes/database/database.inc on line 731

Hm, I tried to reproduce this a couple times and couldn't - the installation worked fine for me with any database prefix (I tried 'drupal_' and 'abc').

What type of database are you using (MySQL? Postgres? What version?)... And was there anything particularly odd or different about the database prefix you used?

For #2, I think that might be a different issue. Seems that at various times similar errors have been reported; I thought they were fixed but it's hard to follow all the different threads. But for example:

#721884: Fatal error: Class 'MergeQuery' not found in D:\education\php\drupal\includes\database\database.inc on line 718
#368116: Fatal error: Class 'MergeQuery_mysql' not found

@cog.rusty, I have no idea why the project issue status was renamed to "postponed" and agree that's misleading (I think it used to be called "active - needs more info"), but that's what it's called. The key idea there was "needs more info". It wasn't intended to downplay the bug.

I think there is a lot more info now (thanks) but it's still not clear how to reliably reproduce it.

However, I looked into it a bit and I think the failure to print the prefix in the error message is probably just a small bug on its own (the error message is generated by the database system before the table prefixing happens). More important, though, I realized that the big code here that did change between and alpha3 and alpha4 is this (in the MySQL driver only):

  public function tableExists($table) {
    // The information_schema table is very slow to query under MySQL 5.0.
    // Instead, we try to select from the table in question.  If it fails,
    // the most likely reason is that it does not exist. That is dramatically
    // faster than using information_schema.
    // @link http: //bugs.mysql.com/bug.php?id=19588
    // @todo: This override should be removed once we require a version of MySQL
    // that has that bug fixed.
    try {
      $this->connection->queryRange("SELECT 1 FROM {" . $table . "}", 0, 1);
      return TRUE;
    }
    catch (Exception $e) {
      return FALSE;
    }
  }

So I wonder what happens on your system if you run a query like this (just on the MySQL command line) - does MySQL generate some kind of exception message or not?

SELECT 1 FROM some_table_that_does_not_exist;

On my machine (MySQL 5.0.51a-3ubuntu5.5) this returns the following.

ERROR 1146 (42S02): Table 'drupal.some_table_that_does_not_exist' doesn't exist

Please try the following snippet on your installation (put that in a .php file and run it in the browser):

$db = new PDO('mysql:host=localhost;dbname=your_db_name', 'your_db_user', 'your_db_pass', array(
  PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
));

try {
  $db->query('SELECT 1 FROM toto');
  echo "Test failed.";
}
catch (Exception $e) {
  echo "Test succeeded (" . (string) $e . ").";
}

And report back the results, along with the exact versions of PHP and MySQL that you are using.

@cog.rusty: any chance you could try to upgrade *only* your PHP installation? ie. keep everything the same (including the MySQL server and client versions). I sense that your version of PDO_MySQL fails to raise an exception.

pecl PDO is not the same as PHP core PDO. If you installed PDO_MYSQL from PECL, you likely have a *really old* version. Try removing that.

Hi David you are correct after careful reading. I read the other threads did not see any solutions. I tried the test you gave below.

And received this.

Test succeeded (exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupalseven.toto' doesn't exist' in /Library/WebServer/dev7-navsixty/pdo-test.php:7 Stack trace: #0 /Library/WebServer/dev7-navsixty/pdo-test.php(7): PDO->query('SELECT 1 FROM t...') #1 {main}).

I'm getting the same error: table variable already exists. #14 is correct about installing pecl install pdo. My results of Damien's comment #8 is: Test failed. In my case, I have repeatedly tried dropping the database and recreating. I've even tried creating a new database without any differences. Visiting index.php, I receive "Fatal error: Call to undefined function system_run_automated_cron() in /var/www/d7/includes/common.inc on line 2444 " BUT install.php works until I receive "table variable already exists." I was using HEAD, but same issue appears in alpha4.

@cog.rusty: yes, I was using suexec. I disabled it, then tried again but same issue.

phpinfo(): http://pastebin.com/s1Rhged8
php.ini: http://pastebin.com/RUhSvnVB
uname -a: Linux debug 2.6.18.8.xs5.0.0.10.439 #1 SMP Wed Aug 6 23:55:12 UTC 2008 i686 GNU/Linux

Here's what I tried:
1. #apt-get install sqlite
2. index.php reports: Fatal error: Class 'PDO' not found in /var/www/d7/includes/database/database.inc on line 178
3. pecl list: (no packages installed from channel pecl.php.net)
4. mods-enabled: http://pastebin.com/An06PERH
5. install.php complains: http://imagebin.org/95760
5b. apt-get remove sqlite
6. pecl install pdo (then uncomment pdo.so in php.ini)
6b. pecl list: PDO 1.0.3 stable
7. index.php shows: Fatal error: Undefined class constant 'MYSQL_ATTR_USE_BUFFERED_QUERY' in /var/www/d7/includes/database/mysql/database.inc on line 33
8. install.php shows: The following error must be resolved before you can continue the installation process:
Error message Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 191 of /var/www/d7/includes/install.inc).
9. pecl uninstall pdo (and uncomment in php.ini)
10. see #5

Solution! After 20 hours of troubleshooting (and not understanding Damien's comment #13), I suspect this a pecl problem. Do NOT USE pecl for pdo_mysql on Lenny! That is unfortunate because Google searches for "install pdo lenny" currently yield this link (http://blog.nethazard.net/how-to-install-php-pdo-on-debian-lenny/), where the suggestion is pecl. However, as explained in a comment from that link, Lenny php5-common and php5-mysql packages *include* the correct pdo extensions, so there's no need to use pecl. I would add that you should AVOID pecl or expect the issues explained above (indeed because pecl compiles a REALLY OLD version that Drupal doesn't like). In case it helps others, I realized that this issue happened to me after "#apt-get dist-upgrade" (from etch to lenny)

Solution:
1. pecl uninstall pdo_mysql
2. pecl uninstall pdo
3. Probably overkill when php5-common and php5-mysql are sufficient, but: #apt-get remove apache2 mysql-server libapache2-mod-php5 libapache2-mod-ruby php5 php5-common php5-curl php5-dev php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-mysql php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
4. run #3 again but "#apt-get install" instead of remove
5. update/verify that your php.ini uses extension=pdo.so and extension=pdo_mysql.so

This works by removing all of the (pecl) pdo.so and pdo_mysql.so files, then reinstalling the newer versions from php5-common and php5-mysql.

Nice sleuthing!

Moving to the database layer component to attract the folks who know about this stuff. And it seems we have enough info now to mark this as 'active'.

At the very least, it seems we need some extra stuff in INSTALL.txt about this problem. But since most people will blindly use Google and come up with the same instructions, it'd be nice of the database layer dealt with this more gracefully. Especially since this is unexpected new behaviour introduced between alpha3 and alpha4.

Also, FYI: Neither of the "postponed" statuses remove an issue from the main issue listing, by design. Only the "closed" type statuses like won't fix, by design, duplicate, etc.

@cog.rusty: >>I am getting is "no pecl? no pdo!". ... I didn't try your "cleanup everything" part because it is a production server and now is not the right time for me to do radical things there.
Yes, I saw that message many times while testing. I suspect, as happened to my server, that because you installed pecl *after* the php5 packages, the "#pecl install pdo_mysql" *overwrote* the php5-common/php5-mysql pdo.so and pdo_mysql.so files with its older versions. Until you replace the pecl .so files with the lenny package versions (via apt-get remove or manually SCP'ing pdo.so and pdo_mysql.so from a similar but non-production lenny box), you probably will see a message like "No PECL, no PDO!"

This should do the trick:

apt-get install --reinstall php5-common php5-mysql

@cog.rusty: please go ahead and fix this page. The instructions for Ubuntu are just plain wrong.

@cog.rusty: the PECL PDO extension *is* outdated, that a fact:

http://pecl.php.net/package/PDO

PDO has been merged into the mainline code of PHP as of PHP 5.1. The PECL extension is *completely unneeded* and *should not* be used. It's pure luck that this extension even builds on PHP 5.2.

Please remove any mention of PECL in the installation instruction, and clarify that if the PECL extension was installed manually, it *has to be* removed.

I opened an issue in the PECL PDO queue: http://pecl.php.net/bugs/bug.php?id=17401

Thanks for your tip, it (#26) solved the issue.

I too get the table variable already exists error
I'm using Bitnami's WAPP stack. I suspect a lot of people might be using that to run Postgresql on Windows.

Can someone help me with a workaround/fix? All the hints above deal with Linux.

I'm using Bitnamis WAPP version WAPPStack 1.2-3 (the latest one as of today)
php_pdo.dll and php_pdo_pgsql.dll (in the php/ext folder) are at version 5.2.14.14
I'm on Windows 7
Drupal Version is 7 beta1

--- this is the relevant section from phpinfo() ---

PDO

PDO support	enabled
PDO drivers	pgsql

pdo_pgsql

PDO Driver for PostgreSQL	enabled
PostgreSQL(libpq) Version	8.3.1
Module version	1.0.2
Revision	 $Id: pdo_pgsql.c 293036 2010-01-03 09:23:27Z sebastian $

This is delt with in #818374: Add a requirements check error if PECL PDO is being used.

I tried installing drupal 7.x-dev on CentOS 5.4 (64-bit) to a PostgreSQL 9.0 database. I'm getting:

Notice: unserialize(): Error at offset 0 of 59 bytes in install_verify_completed_task() (line 784 of /...removed.../drupal/includes/install.core.inc).
Table variable already exists.

Some package versions from my system:
php 5.3.3
php-cli 5.3.3
php-pdo 5.3.3
php-common 5.3.3
php-pgsql 5.3.3

As far as I know I don't have PECL installed - I've never used it and and an rpm -qa | grep pecl doesn't return anything.

@beche-de-mer
Did you find a reference to pecl if you call phpinfo() ?
If not, set the status to "active" in order to notify your issue needs to be fixed

I'm pretty sure #54 is either #722974: Install script returns a blank page for PHP4, PHP 5.1 (should display *something* instead) or #926636: Drupal install error on PostgreSQL 9.0 database.

Table variable already exists. = Error message received when installing Drupal 7.0 RC3 , at Network Solutions, using mysql v5.

This is still a duplicate of #818374: Add a requirements check error if PECL PDO is being used. Please open a new issue if you've found a new bug.

"Table variable already exists". Drupal 7.0 rc3 install on Network Solutions shared hosting. After entering database info, this message appears and stops my installation. Then "Access Forbidden" when I enter my site url http://luxy.biz .

As per #46. Please open a new issue if you have found a new bug that isn't a duplicate of the one mentioned above.

If it still happens on rc3, it cannot be a duplicate.

Need some steps to reproduce here.

I received same error "table variable already exists" when installing pre 7 release with Network Solutions hosting. Investigated and saw previous 6.0 release suggested solution was to adjust php max_execution_time?

Tried to install 7 new release. Initial error: 2006 mySQL server has gone away. Re-entered database information: fatal error "table variable already exists."

When time allows, plan to adjust php execution time. And/or adjust database execution time or time out if it is possible? All suggestions welcomed. Thanks for your help.

If you install and it fails, then you'll need to first empty your database before trying to re-install.

Thanks for the suggestion. However, I have been starting from scratch each time with the code and the database... so this does not appear to be the problem.

So in between these two steps you wiped the db?

"Tried to install 7 new release. Initial error: 2006 mySQL server has gone away. Re-entered database information: fatal error "table variable already exists."

Yes, I wiped everything including the database. Probably user error = me :) Changed php.ini file to increase execution time and size limit. Still, installation failed.

Server issue with Network Solutions shared hosting? I was able to install 7.0 on another shared hosting plan. Baffled and confused!

Side note ran into similar problems with Drupal Commons on both hosting plans. Any suggestions or help on this would be appreciated! Thanks.

ps. would still like to solve Network Solutions problem. Thanks again.

Let's try changing the title and moving this to a support request. If you are getting any errors other than "2006 MySQL server has gone away" please post them.

I am experiencing the same problem. I uploaded drupal 7 (trying to update from 6.20). It would not allow me to finalize the update (I got an error during the process). I decided to do a clean install. Deleted everything, and re-uploaded everything (twice, I am still a newbie so I don't know if I messed something up uploading it and figured I'd just completely do it again.).

I found out that I was having problems with the network solutions, I had to go into the advanced settings and put the database host could not be localhost and had to be the numbered url for my database.

When I finally got passed that database error, I started having the above listed error. The system would report back that "Table variable already exists." I installed it on a newly set up database. I tried both emptying the table and dropping the table. Neither worked. When I would drop the table, the error message would read "Table table_name already exists." But it always seemed to go back to the variable table. I tried dropping all the tables and it would recreate them.

I'm not sure what else to do to make this work. Any help would be appreciated.

"Table variable already exists" during install

Have completely removed total Drupal installation twice

Have both removed and made new mysql database and also tried making a second new database and running install again. Same error

"Table variable already exists"

Made sure I only clicked one time for each "save and continue' button

The only thing I changed, was if (!empty($register_globals) && strtolower($register_globals) == 'off') from !='off') in @ drupal installation folder > modules > system > system.install. Do not believe that affected table variable.

Drupal is new to me, and I am wondering how table vaiables can exist in a clean new database?

putting title back

Network Solutions - shared hosting - install 7.0. Installation works on NS.
It seems that NS changed access to servers and databases.

1. Create database - wait and/or check to make sure actually created (it could take longer than 15 minutes)
2. Upload tar file; Decompress using NS file manager; Move all files from drupal 7.0 folder to correct directory using NS file manager; Create settings.php; Change permissions on settings file; Don't change permission settings for default folder.
3. proceed with install: database host: mysqlv18 or something similar like mysqlv###

Thanks steve.schutte.

I have tried a couple of times. I have both entered the database host as mysqlv12 (the Server Alias NS gives me) and 205.178.146.82 (the IP address that NS gives me). After trying both it comes back with the error that Table Variable already exists. I go and dump and drop the tables that the installation process creates and it keeps not working. Any other ideas where I might be going wrong? Thank you.

Mysqlv### is sufficient and best practice per NS, don't include or use the ip address. Are uploading the tar file and extracting it on the server? For some reason if you ftp the individual files up to the server, you get the error "table variable already exists." Also, once you get the database error, the database needs to be deleted and then recreated. Hope this helps.

see #972528: dblog fails to log MAX_ALLOWED_PACKET errors because they're longer than MAX_ALLOWED_PACKET

I go ahead and close this old issue as it seems to have gotten enough attention.

For future readers: If you have a similar problem, you are welcome to open a new issue.