php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51818 var_dump(): Couldn't fetch mysqli
Submitted: 2010-05-14 03:47 UTC Modified: 2010-05-25 18:55 UTC
Votes:8
Avg. Score:4.0 ± 0.7
Reproduced:7 of 8 (87.5%)
Same Version:4 (57.1%)
Same OS:4 (57.1%)
From: zeusgerde at arcor dot de Assigned: mysql (profile)
Status: Wont fix Package: MySQLi related
PHP Version: 5.3.2 OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2010-05-14 03:47 UTC] zeusgerde at arcor dot de
Description:
------------
E_WARNING when accessing properties or methods of MySQLi object if connection fails

I know other people already reported this kind of issue:
http://bugs.php.net/bug.php?id=33635
http://bugs.php.net/bug.php?id=34828
http://bugs.php.net/bug.php?id=36949
http://bugs.php.net/bug.php?id=45935
http://bugs.php.net/bug.php?id=45940
http://bugs.php.net/bug.php?id=50772

though I think telling the user "couldn't fetch *mysqli*" is just wrong because PHP is able to use the MySQLi object and even some of its properties or methods (e.g. MySQLi::$client_version or MySQLi::$connect_errno)

i am not sure if this is a real bug report or may be a feature request. but I think it would help other people if the warning says something like "mysqli is not connected" or may be E_WARNING should not be raised at all.

--
PHP 5.3.2 (cli) (built: May 14 2010 03:25:13)
MySQLi Client API library version 5.1.45 



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

error_reporting(E_ALL); // not bug related
ini_set('display_errors', 1); // not bug related

$foo = new MySQLi('localhost', 'root', 'wrongpassword');
// alternative to the line above, same result: $foo = new MySQLi();

var_dump($foo);

?>

Expected result:
----------------
object(mysqli)#1 (17) {
/* ... */
}


Actual result:
--------------
Lots of "Warning: var_dump(): Couldn't fetch mysqli in [...]" (for nearly every single key in mysqli)

object(mysqli)#1 (17) {
/* content as expected */
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-05-25 18:55 UTC] andrey@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: mysql
 [2010-05-25 18:55 UTC] andrey@php.net
I think this is a won't fix. The properties of the mysqli or mysql_result object are invalid if the connection establishment or the connection is closed. In case of mysql_result is something wrong happens.
The extension needs different design, new mysqli(...) tries to connect, if something wrong happens it should throw an exception, it doesn't now. The design can't be changed that easily in a minor release.
 [2010-06-17 17:58 UTC] robert dot schlak at alcatel-lucent dot com
The intent of the connect_errno method is to determine if an connection error occurred...one would think. The programmer is expecting the chance a connection error occurred. Don't error-out if he asks.

$host = 'bad_host';// FORCE AN ERROR -- debug
$mysqli = @new mysqli($host, NTSM_USER, PWD_NTSM, NTSM_INSTANCE);
if ($mysqli->connect_errno) {
  do something
}

One would expect the code above to not annoy the user with an echoed warning. I have to use @$mysqli->connect_errno, but I have no return from the method call. Instead I receive 'Couldn't fetch mysqli in', why is a fetch even attempted with this method? Look at the local object and see if it contains an error status and return it.
 [2010-11-16 11:39 UTC] php at ianco dot co dot uk
I have a shopping cart object stored serialized in a database session. This object has a mysqli object as a property, which is left open for reuse.
I was getting the "Couldn't fetch" error every time a new Ajax call tried to access the mysqli object (with OOP) (unless this was a brand new session and the mysqli object had only just been created).
I think the problem is that the database connection is lost between Ajax calls. I have solved it for now by adding a destructor to the cart object, which does mysqli->close() (if the object exists - my cart only instantiates it if needed, not in the cart constructor). 
I haven't checked, but it might also be possible to solve the problem with __sleep. Or you could just be more ruthless and ensure that you never ever leave the mysqli object open.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Mon Dec 06 15:03:34 2021 UTC