oci_free_statement
(PHP 5, PECL OCI8 >= 1.1.0)
oci_free_statement — Frees all resources associated with statement or cursor
Description
bool oci_free_statement
( resource
$statement
)Frees resources associated with Oracle's cursor or statement, which was received from as a result of oci_parse() or obtained from Oracle.
Parameters
-
statement -
A valid OCI statement identifier.
Return Values
Returns TRUE on success or FALSE on failure.
- PHP Руководство
- Функции по категориям
- Индекс функций
- Справочник функций
- Расширения для работы с базами данных
- Расширения для работы с базами данных отдельных производителей
- Oracle OCI8
- oci_bind_array_by_name
- oci_bind_by_name
- oci_cancel
- oci_client_version
- oci_close
- oci_commit
- oci_connect
- oci_define_by_name
- oci_error
- oci_execute
- oci_fetch_all
- oci_fetch_array
- oci_fetch_assoc
- oci_fetch_object
- oci_fetch_row
- oci_fetch
- oci_field_is_null
- oci_field_name
- oci_field_precision
- oci_field_scale
- oci_field_size
- oci_field_type_raw
- oci_field_type
- oci_free_descriptor
- oci_free_statement
- oci_get_implicit_resultset
- oci_internal_debug
- oci_lob_copy
- oci_lob_is_equal
- oci_new_collection
- oci_new_connect
- oci_new_cursor
- oci_new_descriptor
- oci_num_fields
- oci_num_rows
- oci_parse
- oci_password_change
- oci_pconnect
- oci_result
- oci_rollback
- oci_server_version
- oci_set_action
- oci_set_client_identifier
- oci_set_client_info
- oci_set_edition
- oci_set_module_name
- oci_set_prefetch
- oci_statement_type
Коментарии
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.
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.
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...