General error 2014 cannot execute queries while other unbuffered queries are active

My server runs CentOS 6.4 with MySQL 5.1.69 installed using yum with CentOS’s repos, and PHP 5.4.16 installed using yum with ius’s repos. Edit3 Upgraded to MySQL Server version: 5.5.31 Distributed by The IUS Community Project, and error still exists. Then changed library to mysqlnd, and seems to eliminate the error. Still, with this back and forth, need to know why this error only sometimes manifests.

When using PDO and creating the PDO object using PDO::ATTR_EMULATE_PREPARES=>false, I sometimes get the following error:

Table Name - zipcodes
Error in query:
SELECT id FROM cities WHERE name=? AND states_id=?
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
File Name: /var/www/initial_install/build_database.php
Line: 547
Time of Error: Tuesday July 2, 2013, 5:52:48 PDT

Line 547 is the last line of:

$stmt_check_county->execute(array($data[5],$data[4]));
if(!$county_id=$stmt_check_county->fetchColumn())
{
    $stmt_counties->execute(array($data[5]));
    $county_id=db::db()->lastInsertId();
}
//$stmt_check_county->closeCursor(); //This will fix the error
$stmt_check_city->execute(array($data[3],$data[4]));

I had a similar problem several years ago, but upgraded from PHP 5.1 to PHP 5.3 (and MySQL probably was updated as well), and the problem magically went away, and now I have it with PHP 5.5.

Why does it only manifest itself when PDO::ATTR_EMULATE_PREPARES=>false, and with only alternating version of PHPs?

I’ve also found that closeCursor() will also fix the error. Should this always be done after every SELECT query where fetchAll() is not used? Note that the error still occurs even if the query is something like SELECT COUNT(col2) which only returns one value.

Edit By the way, this is how I create my connection. I’ve only recently added MYSQL_ATTR_USE_BUFFERED_QUERY=>true, however, it doesn’t cure the error. Also, the following script could be used as is to create the error.

function sql_error($e,$sql=NULL){return('<h1>Error in query:</h1><p>'.$sql.'</p><p>'.$e->getMessage().'</p><p>File Name: '.$e->getFile().' Line: '.$e->getLine().'</p>');}

class db {
    private static $instance = NULL;
    private function __construct() {}   //Make private
    private function __clone(){}   //Make private
    public static function db() //Get instance of DB
    {
        if (!self::$instance)
        {
            //try{self::$instance = new PDO("mysql:host=localhost;dbname=myDB;charset=utf8",'myUsername','myPassword',array(PDO::ATTR_EMULATE_PREPARES=>false,PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION,PDO::ATTR_DEFAULT_FETCH_MODE=>PDO::FETCH_ASSOC));}
            try{self::$instance = new PDO("mysql:host=localhost;dbname=myDB;charset=utf8",'myUsername','myPassword',array(PDO::ATTR_EMULATE_PREPARES=>false,PDO::MYSQL_ATTR_USE_BUFFERED_QUERY=>true,PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION,PDO::ATTR_DEFAULT_FETCH_MODE=>PDO::FETCH_ASSOC));}
            //try{self::$instance = new PDO("mysql:host=localhost;dbname=myDB;charset=utf8",'myUsername','myPassword',array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION,PDO::ATTR_DEFAULT_FETCH_MODE=>PDO::FETCH_ASSOC));}
            catch(PDOException $e){echo(sql_error($e));}
        }
        return self::$instance;
    }
}

$row=array(
    'zipcodes_id'=>'55555',
    'cities_id'=>123
);
$data=array($row,$row,$row,$row);

$sql = 'CREATE TEMPORARY TABLE temp1(temp_id INT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (temp_id) )';
db::db()->exec($sql);

$sql='SELECT COUNT(*) AS valid FROM cities_has_zipcodes WHERE cities_id=? AND zipcodes_id=?';
$stmt1 = db::db()->prepare($sql);

$sql ='SELECT temp_id FROM temp1';
$stmt2 = db::db()->prepare($sql);

foreach($data AS $row)
{
    try
    {
        $stmt1->execute(array($row['zipcodes_id'],$row['cities_id']));
        $rs1 = $stmt1->fetch(PDO::FETCH_ASSOC);
        //$stmt1->closeCursor();
        syslog(LOG_INFO,'$rs1: '.print_r($rs1,1).' '.rand());
        $stmt2->execute();
        $rs2 = $stmt2->fetch(PDO::FETCH_ASSOC);
        syslog(LOG_INFO,'$rs2: '.print_r($rs2,1).' '.rand());
    }
    catch(PDOException $e){echo(sql_error($e));}            
}
echo('done');

SQLSTATE [HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active.

This error message doesn’t always point you at the right solution.

[PDOException] SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.

PDO::exec() and PDOStatement::execute() are not the same

When working in phinx I found a bug reported by another user where the root of the problem was confusing PDO::exec() and PDOStatement::execute() . Now, phinx makes this easy, because it offers a convenience method on the migration object called «execute», but it is really short hand for «exec()».

PDO::exec() is not designed to run queires that produce result sets. This includes:

PDO::exec() is designed to execute commands and queries that do not produce a result set. Think of SET CHARSET type of commands.

As a side note: you should use SET SQL_MODE=ANSI_QUOTES all the time if you’re using MySQL. It forces you to write more ansi compatible SQL.

Solution

There really is no way to correct an orphaned result set buffer when obtained through exec() . The PDO_mysql extension does not store nor free this result set. The only solution is to change exec() — or in the case of phinx execute() — for query .

The Why

Why does PHP do this? I’m not entirely certain if this is an oversight or not. It should be relatively easy to clean up mistaken result sets like this, and it appears that they do attempt to free some result sets here:

From the MySQL documentation:

Return Values:
-1 indicates that the query returned an error or that, for a SELECT query, mysql_affected_rows() was called prior to calling mysql_store_result().

We can see here that the call to mysql_affected_rows() happens before any mysql_store_result() call, and therefore will return -1 for SELECT queries (and I’m assuming any of the above queries that generate a result set as well).

The behavior of PDO::exec() is well documented. This is not a bug, just user error and confusion created by phinx ‘s helper method names, which are in-turn caused bythe confusingly similar PDO method names exec() and execute() . But, with that said, I’m not sure the block of code that eats up result sets will ever run.

Источник

General error 2014 cannot execute queries while other unbuffered queries are active

SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.n n

The most confusing part is this is not happening regularly, only on 1% of queries or less. Also this started happening recently without any relevant change to the code, so I’m actually suspecting a bug in the mysql php library. n

I already did quite a bit of searching and didn’t really find any helpful solutions. The PDO::MYSQL_ATTR_USE_BUFFERED_QUERY is on by default so the suggestion from error itself is of no use. n

Below is the code fragment containing query execution. n

$query = \DB::connection(‘sip_slave’)n ->table($table . ‘ AS c’)n ->selectRaw(\DB::raw($sql))n ->leftJoin(‘destinations AS d’, ‘d.intDestinationId’, ‘=’, ‘c.destination’)n ->leftJoin(‘tariffData AS td’, ‘td.intTariffDataId’, ‘=’, ‘c.tariffData’)n ->whereRaw($where, [n ‘fromDate’ => $fromDate->format(‘Y-m-d H:i:s’),n ‘toDate’ => $toDate->format(‘Y-m-d H:i:s’),n ‘accountId’ => $account->idn ]);n$query->get();n n

As your issue only happens sometimes it might be related to the variable your passing to the builder n

The only issue I can see on the framework github page is n

It might be worth having a look at the links just incase the trigger a light bulb moment. n

You also are doing a lot of raw queries so you might be better just using DB::select() with a full SQl query. n

Alternatively (and I would say preferably) look at leveraging the power of eloquent and collections n

Sorry I can’t provide any additional code for security reasons, but $sql is just the raw query string which I kept separate to make things cleaner, as it’s a pretty large one. But it doesn’t actually vary between runs. n

I’m a big fan of eloquent and collections but couldn’t use them here due to efficiency reasons. n

In this series, you’ll learn how to drastically improve the performance of your Laravel applications by pushing more work to the database, all while still using the Eloquent ORM.

Источник

Причины ошибки MySQL 2014 Не удается выполнить запросы, в то время как другие небуферизованные запросы активны

Мой сервер запускает CentOS 6.4 с MySQL 5.1.69, установленным с помощью yum с репозиториями CentOS, и PHP 5.4.16, установленным с использованием yum с репозиториями ius. Edit3 Обновлено до версии MySQL Server: 5.5.31 Распространяется проектом сообщества IUS, и ошибка все еще существует. Затем изменили библиотеку на mysqlnd и, похоже, устранили ошибку. Тем не менее, с этим взад и вперед, нужно знать, почему эта ошибка иногда проявляется.

При использовании PDO и создании объекта PDO с использованием PDO::ATTR_EMULATE_PREPARES=>false иногда возникает следующая ошибка:

Строка 547 – это последняя строка:

У меня была аналогичная проблема несколько лет назад, но она обновилась с PHP 5.1 до PHP 5.3 (и MySQL, вероятно, также был обновлен), и проблема волшебно исчезла, и теперь у меня это с PHP 5.5.

Почему это проявляется только тогда, когда PDO::ATTR_EMULATE_PREPARES=>false , и только с чередующейся версией PHP?

Я также обнаружил, что closeCursor() также исправит ошибку. Должно ли это всегда выполняться после каждого запроса SELECT где fetchAll() не используется? Обратите внимание, что ошибка все еще возникает, даже если запрос похож на SELECT COUNT(col2) который возвращает только одно значение.

Edit Кстати, так я создаю свое соединение. Я только недавно добавил MYSQL_ATTR_USE_BUFFERED_QUERY=>true , однако он не излечивает ошибку. Кроме того, можно использовать следующий сценарий, а также создать ошибку.

Solutions Collecting From Web of «Причины ошибки MySQL 2014 Не удается выполнить запросы, в то время как другие небуферизованные запросы активны»

Клиентский протокол MySQL не позволяет выполнять более одного запроса. То есть вы выполнили запрос, и вы получили некоторые результаты, но не все, – тогда вы попытаетесь выполнить второй запрос. Если в первом запросе все еще есть строки для возврата, второй запрос получает ошибку.

Библиотеки клиентов обходятся вокруг этого, выбирая все строки первого запроса неявно при первой выборке, а затем последующие выборки просто перебирают результаты внутри кэширования. Это дает им возможность закрыть курсор (насколько это касается сервера MySQL). Это «буферизованный запрос». Это работает так же, как и с использованием fetchAll (), поскольку оба случая должны выделять достаточно памяти в PHP-клиенте для хранения полного набора результатов.

Разница в том, что буферизованный запрос содержит результат в клиентской библиотеке MySQL, поэтому PHP не может получить доступ к строкам, пока вы не выберете () каждую строку последовательно. В то время как fetchAll () сразу заполняет массив PHP для всех результатов, позволяя вам получить доступ к любой случайной строке.

Основная причина не использовать fetchAll () заключается в том, что результат может быть слишком большим, чтобы вписаться в ваш PHP memory_limit. Но, похоже, ваши результаты запроса имеют только одну строку, так что это не должно быть проблемой.

Вы можете закрытьCursor (), чтобы «отказаться» от результата, прежде чем вы извлекли последнюю строку. Сервер MySQL получает уведомление о том, что он может отменить этот результат на стороне сервера, а затем вы можете выполнить другой запрос. Вы не должны закрыватьCursor (), пока не закончите выбор заданного набора результатов.

Кроме того: я замечаю, что вы выполняете свой $ stmt2 снова и снова внутри цикла, но каждый раз он возвращает тот же результат. По принципу перемещения цикла-инвариантного кода из цикла вы должны выполнить это один раз перед запуском цикла и сохранить результат в переменной PHP. Поэтому, независимо от использования буферизованных запросов или fetchAll (), вам не нужно вставлять ваши запросы.

Поэтому я бы рекомендовал написать свой код таким образом:

Примечание. Я также использовал именованные параметры вместо позиционных параметров, что упрощает передачу $ row в качестве массива значений параметров. Если ключи массива соответствуют именам параметров, вы можете просто передать массив. В старых версиях PHP вам нужно было включить префикс в ключи массива, но вам это больше не нужно.

Вы должны использовать mysqlnd в любом случае. Он имеет больше возможностей, он более эффективен с точки зрения памяти, а его лицензия совместима с PHP.

Я надеюсь на лучший ответ, чем на следующий. Хотя некоторые из этих решений могут «исправить» проблему, они не отвечают на исходный вопрос о том, что вызывает эту ошибку.

1. Установите PDO::ATTR_EMULATE_PREPARES=>true (я не хочу этого делать)
2. Установите PDO::MYSQL_ATTR_USE_BUFFERED_QUERY (не работает для меня)
3. Используйте PDOStatement::fetchAll() (не всегда желательно)
4. Используйте $stmt->closeCursor() после каждого $stmt->fetch() (это в основном работало, однако у меня все еще было несколько случаев, когда это не так)
5. Измените PHP-библиотеку MySQL с php-mysql на php-mysqlnd (возможно, что я буду делать, если не будет лучшего ответа)

У меня почти такая же проблема. Мой первый запрос после подключения к db возвращает пустой результат и отбрасывает эту ошибку. Включение буфера не помогает.

Мой код подключения:

Решение на моем пути состояло в том, чтобы удалить начальную команду:

Вот правильный код:

И MYSQL_ATTR_USE_BUFFERED_QUERY не принуждается к true. Он установлен как значение по умолчанию.

У меня была та же проблема, я отправлял результаты в другую функцию mid loop. Быстрое исправление было, сохраните все результаты в массиве (например, Билл заявил, что если он слишком велик, у вас есть другие проблемы, о которых нужно беспокоиться), после сбора данных я запустил отдельный цикл для вызова функции по одному.

Кроме того, PDO :: MYSQL_ATTR_USE_BUFFERED_QUERY не работал для меня.

Источник

Причины ошибки MySQL 2014 Не удается выполнить запросы, в то время как другие небуферизованные запросы активны

Мой сервер запускает CentOS 6.4 с MySQL 5.1.69, установленным с помощью yum с репозиториями CentOS, и PHP 5.4.16, установленным с использованием yum с репозиториями ius. Edit3 Обновлено до версии MySQL Server: 5.5.31 Распространяется проектом сообщества IUS, и ошибка все еще существует. Затем изменили библиотеку на mysqlnd и, похоже, устранили ошибку. Тем не менее, с этим взад и вперед, нужно знать, почему эта ошибка иногда проявляется.

При использовании PDO и создании объекта PDO с использованием PDO::ATTR_EMULATE_PREPARES=>false иногда возникает следующая ошибка:

Строка 547 – это последняя строка:

У меня была аналогичная проблема несколько лет назад, но она обновилась с PHP 5.1 до PHP 5.3 (и MySQL, вероятно, также был обновлен), и проблема волшебно исчезла, и теперь у меня это с PHP 5.5.

Почему это проявляется только тогда, когда PDO::ATTR_EMULATE_PREPARES=>false , и только с чередующейся версией PHP?

Я также обнаружил, что closeCursor() также исправит ошибку. Должно ли это всегда выполняться после каждого запроса SELECT где fetchAll() не используется? Обратите внимание, что ошибка все еще возникает, даже если запрос похож на SELECT COUNT(col2) который возвращает только одно значение.

Edit Кстати, так я создаю свое соединение. Я только недавно добавил MYSQL_ATTR_USE_BUFFERED_QUERY=>true , однако он не излечивает ошибку. Кроме того, можно использовать следующий сценарий, а также создать ошибку.

Solutions Collecting From Web of «Причины ошибки MySQL 2014 Не удается выполнить запросы, в то время как другие небуферизованные запросы активны»

Клиентский протокол MySQL не позволяет выполнять более одного запроса. То есть вы выполнили запрос, и вы получили некоторые результаты, но не все, – тогда вы попытаетесь выполнить второй запрос. Если в первом запросе все еще есть строки для возврата, второй запрос получает ошибку.

Библиотеки клиентов обходятся вокруг этого, выбирая все строки первого запроса неявно при первой выборке, а затем последующие выборки просто перебирают результаты внутри кэширования. Это дает им возможность закрыть курсор (насколько это касается сервера MySQL). Это «буферизованный запрос». Это работает так же, как и с использованием fetchAll (), поскольку оба случая должны выделять достаточно памяти в PHP-клиенте для хранения полного набора результатов.

Разница в том, что буферизованный запрос содержит результат в клиентской библиотеке MySQL, поэтому PHP не может получить доступ к строкам, пока вы не выберете () каждую строку последовательно. В то время как fetchAll () сразу заполняет массив PHP для всех результатов, позволяя вам получить доступ к любой случайной строке.

Основная причина не использовать fetchAll () заключается в том, что результат может быть слишком большим, чтобы вписаться в ваш PHP memory_limit. Но, похоже, ваши результаты запроса имеют только одну строку, так что это не должно быть проблемой.

Вы можете закрытьCursor (), чтобы «отказаться» от результата, прежде чем вы извлекли последнюю строку. Сервер MySQL получает уведомление о том, что он может отменить этот результат на стороне сервера, а затем вы можете выполнить другой запрос. Вы не должны закрыватьCursor (), пока не закончите выбор заданного набора результатов.

Кроме того: я замечаю, что вы выполняете свой $ stmt2 снова и снова внутри цикла, но каждый раз он возвращает тот же результат. По принципу перемещения цикла-инвариантного кода из цикла вы должны выполнить это один раз перед запуском цикла и сохранить результат в переменной PHP. Поэтому, независимо от использования буферизованных запросов или fetchAll (), вам не нужно вставлять ваши запросы.

Поэтому я бы рекомендовал написать свой код таким образом:

Примечание. Я также использовал именованные параметры вместо позиционных параметров, что упрощает передачу $ row в качестве массива значений параметров. Если ключи массива соответствуют именам параметров, вы можете просто передать массив. В старых версиях PHP вам нужно было включить префикс в ключи массива, но вам это больше не нужно.

Вы должны использовать mysqlnd в любом случае. Он имеет больше возможностей, он более эффективен с точки зрения памяти, а его лицензия совместима с PHP.

Я надеюсь на лучший ответ, чем на следующий. Хотя некоторые из этих решений могут «исправить» проблему, они не отвечают на исходный вопрос о том, что вызывает эту ошибку.

1. Установите PDO::ATTR_EMULATE_PREPARES=>true (я не хочу этого делать)
2. Установите PDO::MYSQL_ATTR_USE_BUFFERED_QUERY (не работает для меня)
3. Используйте PDOStatement::fetchAll() (не всегда желательно)
4. Используйте $stmt->closeCursor() после каждого $stmt->fetch() (это в основном работало, однако у меня все еще было несколько случаев, когда это не так)
5. Измените PHP-библиотеку MySQL с php-mysql на php-mysqlnd (возможно, что я буду делать, если не будет лучшего ответа)

У меня почти такая же проблема. Мой первый запрос после подключения к db возвращает пустой результат и отбрасывает эту ошибку. Включение буфера не помогает.

Мой код подключения:

Решение на моем пути состояло в том, чтобы удалить начальную команду:

Вот правильный код:

И MYSQL_ATTR_USE_BUFFERED_QUERY не принуждается к true. Он установлен как значение по умолчанию.

У меня была та же проблема, я отправлял результаты в другую функцию mid loop. Быстрое исправление было, сохраните все результаты в массиве (например, Билл заявил, что если он слишком велик, у вас есть другие проблемы, о которых нужно беспокоиться), после сбора данных я запустил отдельный цикл для вызова функции по одному.

Кроме того, PDO :: MYSQL_ATTR_USE_BUFFERED_QUERY не работал для меня.

Источник