dbal: PDO exception on version 2.6.2

Issue Resolved I was getting same error. I am running Nginx in Ubuntu 16.04, I have php7.1 installed however it turned out Nginx configuration points to php7.0-fpm.sock

Changing php7.0-fpm.sock to php7.1-fpm.sock resolved this issue

Had the same problem here. Downgrading to composer require doctrine/dbal=2.6.3 did the trick so far. Whenever; i was not able to reproduce in a minimal example on the same machine using https://github.com/doctrine/dbal/issues/2848#issuecomment-379109082 - either via php cli or with mod_php 7.1.16

I have been fighting the same problem myself all afternoon. The tip from DimaUlyanets above got me back on the right track.

I manually set the versions of doctrine/common and doctrine/dbal in my composer.json file, and then rebuilt my app.

relevant settings in composer.json:

"laravel/framework": "5.5.*",
"doctrine/common": "2.7.0",
"doctrine/dbal": "2.5.13"

It was strange, because in my local development environment (homestead) everything was working great. It only caused me problems when I tried to deploy my code to my dev server, which rebuilds the whole app as part of the deployment process.

Had the same issue after updating composer a moment ago. Fixed that issue by rolling back:

• Removing doctrine/common (v2.8.1)

• Installing doctrine/common (v2.7.3)

• Removing doctrine/dbal (v2.7.0)

• Installing doctrine/dbal (v2.5.13)

PHP - 7.1.5 Ubuntu - 16.04

Upgrading PHP-FPM to 7.2 totally did the trick.

@imonroe ~please check the version of your php-fpm. Looks like it’s lower than 7.1 but the code requires ^7.1.~

Looks like you have some other version of DBAL installed. v2.5.13 doesn’t have any void:

https://github.com/doctrine/dbal/blob/729340d8d1eec8f01bff708e12e449a3415af873/lib/Doctrine/DBAL/DriverManager.php#L194

I just found out it is running PHP Version 7.0.29

The person who got it working is not the one who filled the issue but it looks like this can be closed now ? @morozov

I tried the version that was originally in my composer.json, which was causing me problems:

composer.json:

{
    "minimum-stability": "stable",
    "require": {
        "doctrine/dbal": "^2.5"
    }
}

script.php:

<?php
require __DIR__ . '/vendor/autoload.php';
$conn = \Doctrine\DBAL\DriverManager::getConnection([
    'dbname' => 'name',
    'user' => 'user',
    'password' => 'xxxxxxx',
    'host' => '127.0.0.1',
    'driver' => 'pdo_mysql',
]);
$statement = $conn->fetchAll('SELECT * from users');
echo( var_export( $statement, true) );

I did a standard composer update, which pulled in:

  Package operations: 7 installs, 0 updates, 0 removals
  - Installing doctrine/lexer (v1.0.1): Loading from cache
  - Installing doctrine/inflector (v1.3.0): Loading from cache
  - Installing doctrine/collections (v1.5.0): Loading from cache
  - Installing doctrine/cache (v1.7.1): Loading from cache
  - Installing doctrine/annotations (v1.6.0): Loading from cache
  - Installing doctrine/common (v2.8.1): Loading from cache
  - Installing doctrine/dbal (v2.7.0): Loading from cache

Running from CLI, with PHP 7.1.11-1+ubuntu17.10.1+deb.sury.org+1 (cli) And that works with no problems, exactly like I would expect.

HOWEVER!

When I try to run the same script via a web browser, I get a 500 error. I went into my nginx log, and I see:

"PHP message: PHP Fatal error: Uncaught TypeError: Return value of Doctrine\DBAL\DriverManager::_checkParams() must be an instance of Doctrine\DBAL\void, none returned in /path/to//debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php:222

Stack trace: #0 /path/to/debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(165): Doctrine\DBAL\DriverManager::_checkParams(Array) #1 /path/to/debugging/script.php(4): Doctrine\DBAL\DriverManager::getConnection(Array) #2 {main} thrown in /path/to/debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php on line 222" while reading response header from upstream, client: 24.148.94.237, server: myserver.net, request: “GET /debugging/script.php HTTP/1.1”, upstream: “fastcgi://unix:/run/php/php7.0-fpm.sock:”, host: “myserver.net”

You will notice that the the CLI version runs PHP 7.1.11-1+ubuntu17.10.1+deb.sury.org+1 (cli), and the PHP-FPM version runs PHP Version 7.0.28-1+ubuntu17.10.1+deb.sury.org+1 ( according to phpinfo() )

That seems relevant.

So, then I updated my composer.json file, and dumped the vendor directory, and did another composer update. composer.json:

{
    "minimum-stability": "stable",
    "require": {
        "doctrine/dbal": "2.5.13",
        "doctrine/common": "2.7.0"
    }
}

and that installs thusly:

Package operations: 7 installs, 0 updates, 0 removals
  - Installing doctrine/lexer (v1.0.1): Loading from cache
  - Installing doctrine/inflector (v1.3.0): Loading from cache
  - Installing doctrine/collections (v1.5.0): Loading from cache
  - Installing doctrine/cache (v1.7.1): Loading from cache
  - Installing doctrine/annotations (v1.6.0): Loading from cache
  - Installing doctrine/common (v2.7.0): Loading from cache
  - Installing doctrine/dbal (v2.5.13): Loading from cache

I run the script via CLI, and it works just fine. I run the script via php-fpm+nginx and it works just fine.

So there’s certainly a reproduce-able bug somewhere. Is that useful?