oci_free_statement()
(PHP 5, PHP 7, PECL OCI8 >= 1.1.0)
释放关联于语句或游标的所有资源
说明
oci_free_statement(resource $statement): bool
oci_free_statement()释放关联于 Oracle 游标或语句的资源,该资源是作为oci_parse()的结果或者是从 Oracle 取得。
参数
- $statement
有效的 OCI 语句。
返回值
成功时返回TRUE
,或者在失败时返回FALSE
。
oci_free_statement doesn't always free up cursors. I had a query where I performed the following functions in a loop: OCIParse OCIExecute Oci_fetch_assoc (Grab some field values) OciFreeStatement I didn't specify the use of a cursor, but ran into a "maximum open cursors exceeded" error. Within my code, I had one "select * from table_with_lobs" query. When I changed the query to be "select a, b, c, from table_with_lobs" (where I specified the actual column names and where those columns were not LOB fields) the error message went away and I didn't have to resort to upping the max_open_cursors value in Oracle.
If you are using cursors, make sure to free the statement *and* the cursor, especially if there is a possibility of running the proc/cursor again (e.g. with different parameters). <?php oci_execute($stmt); oci_execute($crsr); // iterate through cursor... oci_free_statement($stmt); oci_free_statement($crsr); ?> You need to do it explicitly, closing connection for example does not seem to release the cursor.
A freed statement is not "empty()", it's still a resource: <?php $con=oci_connect(/*connect*/); $q=oci_parse($con,"SELECT sysdate FROM dual"); var_dump($q); // resource(5) of type (oci8 statement) var_dump(empty($q)); // bool(false) var_dump(oci_statement_type($q)); // string(6) "SELECT" echo "------\n"; oci_execute($q); var_dump($q); // same as above var_dump(empty($q)); var_dump(oci_statement_type($q)); echo "------\n"; oci_free_statement($q); var_dump($q); // resource(5) of type (Unknown) var_dump(empty($q)); // bool(false) var_dump(oci_statement_type($q)); // generates warning and returns false oci_close($con); ?> So far I can not think of a way to determine if a statement is freed without using an additional flag...