oci_free_statement

oci_free_statement doesn't always free up cursors.  I had a query where I performed the following functions in a loop:OCIParseOCIExecuteOci_fetch_assoc(Grab some field values)OciFreeStatementI 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 abovevar_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 falseoci_close($con);?>So far I can not think of a way to determine if a statement is freed without using an additional flag...