Bug #73530 [ReO]: Unsetting result set may reset other result set

From: Date: Sat, 22 Feb 2020 15:51:25 +0000
Subject: Bug #73530 [ReO]: Unsetting result set may reset other result set
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-225665@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73530&edit=1 ID: 73530 Updated by: cmb@php.net Reported by: cmb@php.net Summary: Unsetting result set may reset other result set Status: Re-Opened Type: Bug Package: SQLite related Operating System: * PHP Version: master-Git-2016-11-15 (Git) Block user comment: N Private report: N New Comment: An actually related issue: <?php $db = new SQLite3(':memory:'); // let's consider this to be already in the db $db->query("CREATE TABLE dog ( id INTEGER PRIMARY KEY, name TEXT, annoying INTEGER )"); $result = $db->exec("INSERT INTO dog VALUES (1, 'Annoying Dog', 1)"); // process some query $result = $db->query("SELECT 1"); $result->fetchArray(); unset($result); // now trigger an error $result = $db->exec("INSERT INTO dog VALUES (1, 'Annoying Dog', 1)"); var_dump($db->lastErrorCode()); ?> Output: Warning: SQLite3::exec(): UNIQUE constraint failed: dog.id in %s on line %d int(19) That is to be expected; however, if we did not unset($result) explicitly, the output would be: Warning: SQLite3::exec(): UNIQUE constraint failed: dog.id in %s on line %d int(0) In this case the error code is changed, because the SQLite3Result of the "SELECT 1" query is destroyed after the "INSERT INTO" query has been executed, and this triggers the sqlite3_reset() which causes the DB error to be set to zero. Previous Comments: ------------------------------------------------------------------------ [2018-09-24 15:49:07] cmb@php.net Related To: Bug #64531 ------------------------------------------------------------------------ [2017-10-24 16:41:29] cmb@php.net Well, I'm not sure whether this could be solved at all. ------------------------------------------------------------------------ [2017-01-20 15:13:07] it-solutions at schultz dot ch I can confirm that PHP 5.6.30 (in my environment) successfully fixed this issue (tested against PHPExcel library using SQLite3 caching method) Thanks for the work! ------------------------------------------------------------------------ [2017-01-13 10:39:18] cmb@php.net > Please keep in mind that this is also an issue on 5.6.xx and not > only on 7.0.xx/7.1.0! The revert of the BC breaking commit is already in PHP 5.6.30RC1, and as such is supposed to be shipped with PHP 5.6.30. ------------------------------------------------------------------------ [2017-01-13 10:25:27] nikolay dot petkov at peri dot de Working: PHP 5.6.28 Fails: PHP 5.6.29 I have encountered the same issue with one of our deployed applications that uses the PHPOffice/PHPExcel library to generate Excel part lists. After the PHP has been updated on the server, the application crashes due to the bug fix and the external library. Please keep in mind that this is also an issue on 5.6.xx and not only on 7.0.xx/7.1.0! For now I have to rewrite the application to use another cache method... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73530 -- Edit this bug report at https://bugs.php.net/bug.php?id=73530&edit=1

« previous php.bugs (#225665) next »