|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2017-11-23 22:37 UTC] sixd@php.net
-Status: Open
+Status: Feedback
[2017-11-23 22:37 UTC] sixd@php.net
[2017-11-23 22:37 UTC] sixd@php.net
-Assigned To:
+Assigned To: tianfyan
[2018-06-24 04:25 UTC] php-bugs at lists dot php dot net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 14:00:01 2025 UTC |
Description: ------------ Set oci8.statement_cache_size = 30 in php.ini Set open_cursors = 30 in Oracle. Run the script and die on the 31st cursor: Cursor 30 executed Warning: oci_execute(): ORA-01000: maximum open cursors exceeded in /home/dke/work/cursors/php/t2 on line 17 Test script: --------------- #!/bin/env php <?php // Create connection to Oracle $cx = oci_connect("/", "", "TST", null, OCI_CRED_EXT ); if (!$cx) { $m = oci_error(); echo $m['message'], "\n"; exit; } $st = oci_parse($cx, "ALTER SESSION SET tracefile_identifier='T2' SQL_TRACE= TRUE"); oci_execute( $st ); $qry = "select 1 + %d from dual"; for ($i=1; $i<=31; $i++) { $st = oci_parse($cx, sprintf( $qry, $i) ); oci_execute($st, OCI_DEFAULT); oci_fetch_all($st, $res); oci_free_statement( $st ); printf( "Cursor %d executed\n", $i ); } // Close the Oracle connection oci_close($cx); ?> Expected result: ---------------- I expect not to die on ORA-1000. I'm properly closing my cursors, after all. There should be a sanity check on oci8.statement_cache_size that ensures it is strictly inferior to the Oracle parameter open_cursors. Actual result: -------------- Cursor 30 executed Warning: oci_execute(): ORA-01000: maximum open cursors exceeded in /home/dke/work/cursors/php/t2 on line 17