As the paste on the pasteboard is gone I'll add the code here.
-----------

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

$db = @new MySQLi('localhost', '', '', 'test');
if (mysqli_connect_errno()) {
    die('Konnte keine Verbindung zu Datenbank aufbauen, MySQL meldete: '.mysqli_connect_error());
}
echo 'PHP-Version: '.PHP_VERSION."\n";
echo 'MySQL-Server-Version: '.$db->server_version."\n";
echo 'MySQL-Protocol: '.$db->protocol_version."\n";
$sql = 'CREATE TEMPORARY TABLE SomeTest(UserID INT NOT NULL, RechtID INT NOT NULL)';
if (!$db->query($sql)) {
    die($db->error);
}
$sql = 'DELETE FROM
            SomeTest
        WHERE
            UserID = ?';
if (!$stmt = $db->prepare($sql)) {
    die($db->error);
}
// note the missing $stmt->close() here
$sql = 'INSERT INTO
            SomeTest(UserID, RechtID)
        WHERE
            (?,?)';
if (!$stmt = $db->prepare($sql)) {
    die($db->error."-".$db->errno."-".$db->info);
}
echo "done";
?>

The bug is still not fixed. Maybe it has something to do with an uncalled destructor since I use the same variable $stmt.

Actual result:
--------------
PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
-0-

Expected result:
----------------
PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
(Showing a MySQL error which says "Syntax error near WHERE (?,?)" or
says sth. like "unfinished prepare statement before")

It's because the first $stmt object is destroyed by the second assignment (which clears the last error message).

$sql = 'INSERT INTO
            SomeTest(UserID, RechtID)
        WHERE
            (?,?)';
if (!$stmt = $db->prepare($sql)) {
    die($db->error."-".$db->errno."-".$db->info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt->close() explicitly. Probably best to use this syntax:

$sql = 'INSERT INTO
            t(i)
        WHERE
            (?)';
$stmt = $db->stmt_init();
if(!$stmt->prepare($sql) ){
  die( $stmt->error );
}

Sure I can call close() by myself (which I normally do), but it doesn't solve the bug itself. The point is you get an error situation and don't know why.

I don't know what to do with this report because in a way it is a user error. The problem can easily be avoided by calling the destructor of the mysql_statement class before assigning false to it. A simple $stmt->close() before the second $stmt = $db->prepare() will fix it.


What happens is:

 $stmt = ... <valid_sql>
 $stmt = $mysqli->prepare('wrong_sql');

 <switch into php />
 <function_enter> 

    C API: mysql_stmt_init()
    C API: mysql_stmt_prepare() -> error
    copy error, because mysql_stmt_close() will clean it
    C API: mysql_stmt_close()

    RETURN false

 </function_enter>

 <evaluate assignment to $stmt>
    $stmt is a Prepared Statement for <valid_sql>
    destruct $stmt, because user did not clean it up!

    C API: mysql_stmt_close() 
    !!! previously saved error message gets cleaned !!!

 </evaluate assignment to $stmt>

 <assign return value to $stmt />
 <give control back to PHP script />

 var_dump($mysqli->error) -> no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct and copy the error message into some safe place. But I wonder how we would know when to return the message copied into a safe place and when not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd behave different to libmysql (not clean/preserve error message in mysqlnd' stmt dtor) but that would be just the wrong place and really hackish....

Maybe we should set the status to "Won't fix".

After spending the evening on it, I am even more in the mood to change status to "Won't fix".

Even if we copy error messages to a safe place we need to know when to return the prepare error message. We should return the prepare error message, if any mysql C API call made between the failed prepare and the fetch of the error message by the user have succeeded. "Any" refers to all calls made implicitly by the destructor of the overwritten statement object before mysqli->prepare() returns. "Any" must not include calls made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error && no_regular_error)
    clean_and_return_pepare_error;

That simple approach would not ensure that "any" is as small as we want it to be. We would need another flag that tells us if the user has made any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe abuse mysql->mysql->net.errno (a private member) again to check if it gets reset - every C API call resets it. If our special "prepare_error_fetch" flag is gone, the user must have made an API call after prepare. Oh, problem, no mysql->mysql struct available in the statement destructor that calls mysql_stmt_close()... what about introducing a new global structure for tracking to be able to link statements and connections, *ouch* -> "Won't fix"...

Aren't the prepared statement saved in different MYSQL_STMT structs? If so why do one mysql_stmt_close() in one struct clear the last_error field in the other one? Or is the destructor called too late (on the new created statement), after the (php-)objects are relocated/replaced/reassigned?

Simple: there aint no two statement objects. You got one statement object and one statement struct from the first successful statement. The second struct is destroyed before prepare() returns. 

The error messages is communicated to mysql_error using the connection object, the mysql struct.

Uwe, don't bother.