Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68622 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76337 invoked from network); 25 Aug 2013 05:52:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Aug 2013 05:52:25 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:60904] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E7/1A-05399-89B99125 for ; Sun, 25 Aug 2013 01:52:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 68484148077; Sun, 25 Aug 2013 01:52:22 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C2935148092; Sun, 25 Aug 2013 01:52:21 -0400 (EDT) Message-ID: <52199B95.1060100@sugarcrm.com> Date: Sat, 24 Aug 2013 22:52:21 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "mysql@php.net" , Ulf Wendel , Ilia Alshanetsky , =?ISO-8859-1?Q?Johannes_Schl=FCter?= , PHP Internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: pdo_mysql and bug_39858.phpt From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! I'm looking into tests fails that I get with mysqlnd and mysql enabled, and on bug_39858.phpt I've noticed a strange thing. The code goes like this: $stmt = $db->prepare("CALL p()"); $stmt->execute(); do { var_dump($stmt->fetchAll(PDO::FETCH_ASSOC)); } while ($stmt->nextRowset()); And the test tests it in emulation mode and native mode. However these modes work differently. If you look at mysq_statement.c, specifically into pdo_mysql_stmt_next_rowset, then after "if (!H->emulate_prepare)" the code discards last rowset, with the comment: MySQL gives us n + 1 result sets for CALL proc() and n result sets returned by the proc itself. Result set n + 1 is about the procedure call itself. As the PDO emulation does not return it, we skip it as well However, the code after that does not discard last rowset (line 414 and below), instead it returns true and then fetchAll fails on this one with: Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error This happens only if it is compiled with mysqlnd and only after $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, 1); Any ideas what's going on and why the emulation code does not discard the last rowset? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227