[ library(dbi) | Reference Manual | Alphabetic Index ]
cursor_next_execute(++Cursor, +Tuple, ++Options)
Executes the parametrised prepared SQL statement represented by Cursor, with options Options.
- A cursor handle
- A tuple of parameter values matching the template for this cursor (structure)
- Options (list of Option:Value pairs or nil)
Executes the parameterised prepared SQL statement represented by Cursor,
previously prepared by session_sql_prepare/4 or session_sql_prepare_query/5.
The parameter values for this execution is supplied by Tuple. Options is
a (possibly empty) list of Option:Value pairs, specifying
DBMS-specific options for the cursor.
Tuple is a structure whose name and arity match the parameter template
when Cursor was prepared, and the arguments give the values for the
parameters for this execution, and must be compatible with the type
specified by the template, except that an argument can be an
uninstantiated variable, to denote a NULL value for the corresponding
If the SQL statement is a query, and was prepared as a query using
session_sql_prepare_query/5, results can be obtained from the query by
the cursor_*_tuple family of predicates.
Options is used to specify the type of cursor used. Currently this only
applies to cursors for SQL queries. The options are:
- Specifies where the result set of a SQL query is buffered. Value can be
either client (the default) or server. By default, the
whole of the result set for a query is copied to the client (i.e. the
ECLiPSe process running lib(dbi)) after the SQL query is executed. The
alternative is to leave the result set on the DBMS server, and only get
the result tuples from the server one by one (with e.g. cursor_next_tuple/2).
The default buffering is on the client side, because this is the default
of the MySQL C API, and in addition, it imposes certain restrictions on
how the result tuples can be retrieved. However, as the whole result set
is retreived, this can impose significant memory overheads if there are
many tuples in the result set.
- Specifies the type of cursor, and is only meaningful if the buffering
option is set to server. Value can be either no_cursor (the
default) or read_only. These correspond to the MySQL statement
attribute STMT_ATTR_CURSOR_TYPE of CURSOR_TYPE_NO_CURSOR and
CURSOR_TYPE_READ_ONLY respectively (See the MySQL manual for details).
Only one active cursor of type no_cursor is allowed per session, and this
active cursor must be closed before another query can be issued to the
DBMS server. read_only cursor does not have this restriction, and several
such cursors can be active at the same time.
- (5) type error
- Cursor is not a valid cursor handle
- (5) type error
- Type mismatch between parameter template specification for Cursor and actual tuple data
- (6) out of range
- Invalid option specification in Options
- Parameter value(s) too big for the buffer
- Error from DBMS while executing SQL associated with Cursor.
- ParamTemplate not specified when Cursor was created
- The Cursor is not in a state to execute a query (e.g. it was cancelled)
cursor_next_execute / 2, cursor_all_execute / 2, cursor_N_execute / 4, session_sql_prepare / 4, session_sql_prepare_query / 5