php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #52302 mysqli_fetch_all does not work with MYSQLI_USE_RESULT
Submitted: 2010-07-10 10:39 UTC Modified: 2010-08-11 10:01 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: brianlmoon@php.net Assigned: andrey (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.3.2 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: brianlmoon@php.net
New email:
PHP Version: OS:

 

 [2010-07-10 10:39 UTC] brianlmoon@php.net 
Description:
------------
When using MYSQLI_USE_RESULT as the second parameter to mysqli_query, fetch_all returns null.

Test script:
---------------
<?php

$m = new MySQLi("", "root", "", "information_schema");

$sql = "show tables";

$res = $m->query($sql, MYSQLI_USE_RESULT);

$rows = $res->fetch_all();

var_dump($rows);

?>

Expected result:
----------------
An array of the table data.

Actual result:
--------------
NULL

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-07-10 16:32 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: mysql
 [2010-07-12 18:16 UTC] brad at njoe dot com 
Confirmed on Windows build as well using: PHP 5.3.2 (cli) (built: Mar  3 2010 
19:40:13).

Even SELECT'ing a static string (e.g. SELECT 'This is a test.') exhibits this 
behavior.
 [2010-07-13 10:36 UTC] andrey@php.net
-Status: Assigned +Status: Bogus
 [2010-07-13 10:36 UTC] andrey@php.net 
Makes no sense to use USE_RESULT and buffer the result. Use STORE_RESULT, it is more effective for fetch_all(). Artifically limited.
 [2010-07-16 17:42 UTC] brianlmoon@php.net
-Status: Bogus +Status: Open
 [2010-07-16 17:42 UTC] brianlmoon@php.net 
No, it makes perfect sense. In fact, it should be the preferred way to use fetch_all. Why store the data only to dump it into a PHP array on the next line? That is a very inefficient use of memory and plain careless development.

Or do you mean to say that fetch_all is fundamentally broken and will only work with STORE_RESULT?
 [2010-08-05 14:11 UTC] johannes@php.net 
The key point here is that the stored buffer can directly be used for fetch_all. The fetch_all does nothing but increasing the ref counts on the buffered values and adding them to an array. doing this with USE_RESULT would do an implicit STORE_RESULT.

Marking this a Feature request.
 [2010-08-05 14:12 UTC] johannes@php.net
-Type: Bug +Type: Feature/Change Request
 [2010-08-09 19:29 UTC] andrey@php.net 
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=302045
Log: Fix Request #52302 mysqli_fetch_all does not work with MYSQLI_USE_RESULT
 [2010-08-09 19:37 UTC] andrey@php.net
-Status: Assigned +Status: Closed
 [2010-08-09 19:37 UTC] andrey@php.net 
Fix will appear in 5.3.4 
In any case, it is sub-optimal to use MYSQLI_USE_RESULT with fetch_all, compared to MYSQLI_STORE_RESULT. However, fetch_all with USE_RESULT should be faster than manually looping.
 [2010-08-10 01:43 UTC] brianlmoon@php.net 
Can we get an E_WARNING when fetch_all is called with a result handle that is using USE_RESULT? Can the documentation be updated to include a notice that this will not work?
 [2010-08-11 10:01 UTC] andrey@php.net
-Assigned To: mysql +Assigned To: andrey
 [2010-08-11 10:01 UTC] andrey@php.net 
USE_RESULT will work, as of 5.3.4 (already in svn). E_WARNING or E_NOTICE?
I mean, it is good for consistency to have it work for both. Sometimes you might get a result set, as a parameter, and don't know where it came from, you should not fail because it was unbuffered. Thus, E_WARNING is a bit too much, IMO, but maybe E_NOTICE...
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC