Bug #73530 [ReO]: Unsetting result set may reset other result set
| From: | cmb@php.net | 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