oci_field_type
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.
oci_free_statement
(PHP 5, PECL oci8 >= 1.1.0)
oci_free_statement — Libère toutes les ressources réservées par un résultat Oracle
Description
bool oci_free_statement
( resource $statement
)
Libère toutes les ressources réservées par le résultat ou curseur Oracle statement . Ce dernier a été obtenu de la fonction oci_parse(), ou directement de Oracle.
Liste de paramètres
- statement
-
Un identifiant de requête OCI valide.
Valeurs de retour
Cette fonction retourne TRUE en cas de succès, FALSE en cas d'échec.
add a note
User Contributed Notesoci_free_statement
Jen M.
02-Oct-2008 06:05
02-Oct-2008 06:05
rada at instinctive dot it
04-Mar-2008 04:46
04-Mar-2008 04:46
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.