= Programming with SQL Relay using the Perl API =

* [#session Establishing a Session]
* [#query Executing Queries]
* [#commit Commits and Rollbacks]
* [#temptables Temporary Tables]
* [#errors Catching Errors]
* [#bindvars Substitution and Bind Variables]
* [#rebinding Re-Binding and Re-Executing]
* [#fields Accessing Fields in the Result Set]
* [#largeresultsets Dealing With Large Result Sets]
* [#cursors Cursors]
* [#columns Getting Column Information]
* [#storedprocedures Stored Procedures]
* [#caching Caching The Result Set]
* [#suspending Suspending and Resuming Sessions]
* [#lastinsertid Getting the Last Insert ID]

[=#session]
== Establishing a Session ==

To use SQL Relay, you have to identify the connection that you intend to 
use.

{{{#!blockquote
{{{#!code
@parts/perl-session.pl@
}}}
}}}

After calling the constructor, a session is established when the first 
query is run.

For the duration of the session, the client occupies one of the database
connections, so care should be taken to minimize the length of a
session.

Sessions can also be encrypted and authenticated using Kerberos/Active Directory or TLS/SSL.  The enableKerberos() method is provided to enable Kerberos/Active Directory encryption and authentication and the enableTls() method is provided to enable TLS/SSL encryption and authentication.  The disableEncryption() method is provided to disable any previously enabled encryption.

See the [../api/perl/Connection.html SQLRelay::Connection class reference] for information about these methods and the SQL Relay Configuration Guide for more information about [../admin/configguide.html#krb Kerberos/Active Directory] and [../admin/configguide.html#tls TLS/SSL] configurations.  In particular, note that user and password are not typically used when using Kerberos/AD.

[=#query]
== Executing Queries ==

Call sendQuery() or sendFileQuery() to run a query.

{{{#!blockquote
{{{#!code
@parts/perl-execute.pl@
}}}
}}}

Note the call to endSession() after the call to sendFileQuery().  Since the
program does some stuff that takes a long time between that query and the next,
ending the session there allows another client an opportunity to use that
database connection while your client is busy.  The next call to sendQuery() 
establishes another session.  Since the program does some stuff that takes a 
short time between the first two queries, it's OK to leave the session open 
between them.

[=#commit]
== Commits and Rollbacks ==

If you need to execute a commit or rollback, you should use the commit()
and rollback() methods of the SQLRelay::Connection class rather than 
sending a "commit" or "rollback" query.  There are two reasons for this.  
First, it's much more efficient to call the methods.  Second, if you're writing 
code that can run on transactional or non-transactional databases, some 
non-transactional databases will throw errors if they receive a "commit" or 
"rollback" query, but by calling the commit() and rollback() methods you 
instruct the database connection daemon to call the commit and rollback API 
methods for that database rather than issuing them as queries.  If the API's 
have no commit or rollback methods, the calls do nothing and the database 
throws no error.

You can also turn Autocommit on or off with the autoCommitOn() and
autoCommitOff() methods of the SQLRelay::Connection class.  When 
Autocommit is on, the database performs a commit after each successful DML or 
DDL query.  When Autocommit is off, the database commits when the client 
instructs it to, or (by default) when a client disconnects.  For databases that
don't support Autocommit, autoCommitOn() and autoCommitOff() have no effect.

[=#temptables]
== Temporary Tables ==

Some databases support temporary tables.  That is, tables which are
automatically dropped or truncated when an application closes its connection
to the database or when a transaction is committed or rolled back.

For databases which drop or truncate tables when a transaction is committed
or rolled back, temporary tables work naturally.

However, for databases which drop or truncate tables when an application
closes its connection to the database, there is an issue.  Since SQL Relay
maintains persistent database connections, when an application disconnects from
SQL Relay, the connection between SQL Relay and the database remains, so
the database does not know to drop or truncate the table.  To remedy this
situation, SQL Relay parses each query to see if it created a temporary table,
keeps a list of temporary tables and drops (or truncates them) when the
application disconnects from SQL Relay.  Since each database has slightly
different syntax for creating a temporary table, SQL Relay parses each query
according to the rules for that database.

In effect, temporary tables should work when an application connects to
SQL Relay in the same manner that they would work if the application connected
directly to the database.

[=#errors]
== Catching Errors ==

If your call to sendQuery() or sendFileQuery() returns a 0, the query failed.
You can find out why by calling errorMessage().

{{{#!blockquote
{{{#!code
@parts/perl-errors.pl@
}}}
}}}


[=#bindvars]
== Substitution and Bind Variables ==

Programs rarely execute fixed queries.  More often than not, some part
of the query is dynamically generated.  The SQL Relay API provides methods for
making substitutions and binds in those queries.

For a detailed discussion of substitutions and binds, see
[binds.html this document].

Rather than just calling sendQuery() you call prepareQuery(),
substitution(), inputBind() and executeQuery().  If you using queries
stored in a file, you can call prepareFileQuery() instead of prepareQuery().

When passing a floating point number in as a bind or substitution variable,
you have to supply precision and scale for the number.  See
[precisionscale.html this page] for a discussion of precision and
scale.

{{{#!blockquote
{{{#!code
@parts/perl-bind.pl@
}}}
}}}

If you are curious how many bind variables have been declared in a query,
you can call countBindVariables() after preparing the query.

If you're using a database with an embedded procedural language, you may
want to retrieve data from function calls.  To facilitate this, SQL Relay
provides methods for defining and retrieving output bind variables.

{{{#!blockquote
{{{#!code
@parts/perl-bind-out.pl@
}}}
}}}

The getOutputBindString() method returns a NULL value as an empty string.  
If you would it to come back as a NULL instead, you can call the 
getNullsAsNulls() method.  To revert to the default behavior, you can
call getNullsAsEmptyStrings().

You can insert data into BLOB and CLOB columns using the inputBindBlob(),
inputBindClob() methods.

{{{#!blockquote
{{{#!code
@parts/perl-bind-lob.pl@
}}}
}}}

Likewise, you can retreive BLOB or CLOB data using
defineOutputBindBlob()/getOutputBindBlob() and
defineOutputBindClob()/getOutputBindClob().

{{{#!blockquote
{{{#!code
@parts/perl-bind-lob-out.pl@
}}}
}}}

Sometimes its convenient to bind a bunch of variables that may or may not 
actually be in the query.  For example, if you are building a web based
application, it may be easy to just bind all the form variables/values from the
previous page, even though some of them don't appear in the query.  Databases
usually generate errors in this case.  Calling validateBinds() just prior to
calling executeQuery() causes the API to check the query for each bind variable
before actually binding it, preventing those kinds of errors.   You can also
call validBind() to see if a specific variable is valid.  However there is
a performance cost associated with calling validateBinds() and validBind().

[=#rebinding]
== Re-Binding and Re-Execution ==

Another feature of the prepare/bind/execute paradigm is the ability to 
prepare, bind and execute a query once, then re-bind and re-execute the query 
over and over without re-preparing it.  If your backend database natively 
supports this paradigm, you can reap a substantial performance improvement.

{{{#!blockquote
{{{#!code
@parts/perl-reexecute.pl@
}}}
}}}

[=#fields]
== Accessing Fields in the Result Set ==

The rowCount(), colCount() and getField() methods are useful for processing
result sets.

{{{#!blockquote
{{{#!code
@parts/perl-fields.pl@
}}}
}}}

The getField() method returns a string.  If you would like to get a field as
a long or double, you can use getFieldAsLong() and getFieldAsDouble().

You can also use getRow() or getRowHash() to get the entire row.


{{{#!blockquote
{{{#!code
@parts/perl-fields-row.pl@
}}}
}}}

The getField(), getRow() and getRowHash() methods return NULL fields as 
empty strings.  If you would like them to come back as NULL's instead, you can 
call the getNullsAsNulls() method.  To revert to the default behavior, you can 
call getNullsAsEmptyStrings().

If you want to access the result set, but don't care about the
column information (column names, types or sizes) and don't mind getting
fields by their numeric index instead of by name,  you can call the
dontGetColumnInfo() method prior to executing your query.  This can result
in a performance improvement, especially when many queries with small
result sets are executed in rapid succession.  You can call getColumnInfo()
again later to turn off this feature.

[=#largeresultsets]
== Dealing With Large Result Sets ==

SQL Relay normally buffers the entire result set.  This can speed things up 
at the cost of memory.  With large enough result sets, it makes sense to buffer the result set in chunks instead of all at once.

Use setResultSetBufferSize() to set the number of rows to buffer at a time.
Calls to getRow(), getRowHash() and getField() cause the chunk containing the 
requested field to be fetched.  Rows in that chunk are accessible but rows 
before it are not.

For example, if you setResultSetBufferSize(5) and execute a query that 
returns 20 rows, rows 0-4 are available at once, then rows 5-9, then 10-14, 
then 15-19.  When rows 5-9 are available, getField(0,0) will return NULL and 
getField(11,0) will cause rows 10-14 to be fetched and return the requested
value.

When buffering the result set in chunks, don't end the session until after
you're done with the result set.

If you call setResultSetBufferSize() and forget what you set it to, you
can always call getResultSetBufferSize().

When buffering a result set in chunks, the rowCount() method returns
the number of rows returned so far.  The firstRowIndex() method returns the
index of the first row of the currently buffered chunk.

{{{#!blockquote
{{{#!code
@parts/perl-rsbuffersize.pl@
}}}
}}}

[=#cursors]
== Cursors ==

Cursors make it possible to execute queries while processing the result
set of another query.  You can select rows from a table in one query, then 
iterate through its result set, inserting rows into another table, using only 
1 database connection for both operations.

For example:

{{{#!blockquote
{{{#!code
@parts/perl-cursors.pl@
}}}
}}}

If you are using stored procedures with Oracle, a stored
procedure can execute a query and return a cursor.  A cursor bind variable can
then retrieve that cursor.  Your program can retrieve the result set from the
cursor.  All of this can be accomplished using defineOutputBindCursor(),
getOutputBindCursor() and fetchFromOutputBindCursor().

{{{#!blockquote
{{{#!code
@parts/perl-bind-cursor.pl@
}}}
}}}

The number of cursors simultaneously available per-connection is set at 
compile time and defaults to 5.

[=#columns]
== Getting Column Information ==

For each column, the API supports getting the name, type and length of each
field.  All databases support these attributes.  The API also supports
getting the precision, scale (see [precisionscale.html this page]
for a discussion of precision and scale), length of the longest field, and
whether the
column is nullable, the primary key, unique, part of a key, unsigned,
zero-filled, binary, or an auto-incrementing field.  However, not all databases
support these attributes.  If a database doesn't support an attribute, it is
always returned as false.

{{{#!blockquote
{{{#!code
@parts/perl-columninfo.pl@
}}}
}}}

Some databases force column names to upper case, others force column names
to lower case, and others still support mixed-case column names.  Sometimes,
when migrating between databases, you can run into trouble.  You can use
upperCaseColumnNames() and lowerCaseColumnNames() to cause column names to be
converted to upper or lower case, or you can use mixedCaseColumnNames() to
cause column names to be returned in the same case as they are defined in the
database.

{{{#!blockquote
{{{#!code
@parts/perl-columncase.pl@
}}}
}}}


[=#storedprocedures]
== Stored Procedures ==

Many databases support stored procedures.  Stored procedures are sets of
queries and procedural code that are executed inside of the database itself.
For example, a stored procedure may select rows from one table, iterate through
the result set and, based on the values in each row, insert, update or delete
rows in other tables.  A client program could do this as well, but a stored
procedure is generally more efficient because queries and result sets don't
have to be sent back and forth between the client and database.  Also, stored
procedures are generally stored in the database in a compiled state, while
queries may have to be re-parsed and re-compiled each time they are sent.

While many databases support stored procedures.  The syntax for creating
and executing stored procedures varies greatly between databases.

Stored procedures typically take input paramters from client programs through
input bind variables and return values back to client programs either through
bind variables or result sets.  Stored procedures can be broken down into
several categories, based on the values that they return.  Some stored
procedures don't return any values, some return a single value, some return
multiple values and some return entire result sets.

=== No Values ===

Some stored procedures don't return any values.  Below are examples,
illustrating how to create, execute and drop this kind of stored procedure for
each database that SQL Relay supports.

==== Oracle ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-oracle-testproc.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-drop-testproc.sql@
}}}
}}}


==== Sybase and Microsoft SQL Server ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-sybase-testproc.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-drop-testproc.sql@
}}}
}}}

==== Firebird ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-firebird-testproc.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-drop-testproc.sql@
}}}
}}}

==== DB2 ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-db2-testproc.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-drop-testproc.sql@
}}}
}}}

==== Postgresql ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-postgresql-testproc.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-drop-testproc.sql@
}}}
}}}

==== !MySQL ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc.cpp@
}}}
}}}

Note: Versions of !MySQL prior to 5.0 had trouble calling stored procedures using bind variables.  If you are using a version of !MySQL prior to 5.0 then SQL relay must fake the bind variables and you must use colon-delimited variables (:1, :2, :3, etc.) in your queries rather than the native-mysql queston marks.

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}



=== Single Values ===

Some stored procedures return single values.  Below are examples,
illustrating how to create, execute and drop this kind of stored procedure for
each database that SQL Relay supports.

==== Oracle ====

In Oracle, stored procedures can return values through output parameters or
as return values of the procedure itself.

Here is an example where the procedure itself returns a value.  Note that
Oracle calls these functions.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-create-testproc-1value.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-oracle-testproc-1value.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-drop-testproc.sql@
}}}
}}}

Here is an example where the value is returned through an output
parameter.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-create-testproc-1value-output-param.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-oracle-testproc-1value-output-param.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-drop-testproc.sql@
}}}
}}}


==== Sybase and Microsoft SQL Server ====

In Sybase and Microsoft SQL Server, stored procedures return values
through output parameters rather than as return values of the procedure
itself.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-create-testproc-1value.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-sybase-testproc-1value.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-drop-testproc.sql@
}}}
}}}


==== Firebird ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-drop-testproc.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-firebird-testproc-1value.cpp@
}}}
}}}

Alternatively, you can run a query like the following and receive the result
using an output bind variable.  Note that in Firebird, input and
output bind variable indices are distict from one another.  The index of the
output bind variable is 1 rather than 4, even though there were 3 input bind
variables.

{{{#!blockquote
{{{#!code
@parts/c++-firebird-testproc-1value-output-param.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-drop-testproc.sql@
}}}
}}}


==== DB2 ====

In DB2, stored procedures return values through output parameters rather
than as return values of the procedure itself.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-create-testproc-1value.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-db2-testproc-1value.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-drop-testproc.sql@
}}}
}}}


==== Postgresql ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-create-testproc-1value.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-postgresql-testproc-1value.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-drop-testproc-1value.sql@
}}}
}}}

==== !MySQL ====

A single value can be returned from a !MySQL function.

To create the function, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-1value.sql@
}}}
}}}

To execute the function from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-1value.cpp@
}}}
}}}

Note: Versions of !MySQL prior to 5.0 had trouble calling stored procedures using bind variables.  If you are using a version of !MySQL prior to 5.0 then SQL relay must fake the bind variables and you must use colon-delimited variables (:1, :2, :3, etc.) in your queries rather than the native-mysql queston marks.

To drop the function, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}

A single value can be returned in the result set of a !MySQL procedure.

To create the procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-1value-result-set.sql@
}}}
}}}

To execeute the procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-1value-result-set.cpp@
}}}
}}}

To drop the procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}

A single value can be returned using the output variable of a !MySQL
procedure.

To create the procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-1value-output-param.sql@
}}}
}}}

To execeute the procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-1value-output-param.cpp@
}}}
}}}

To drop the procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}



=== Multiple Values ===

Some stored procedures return multiple values.  Below are examples,
illustrating how to create, execute and drop this kind of stored procedure for
each database that SQL Relay supports.

==== Oracle ====

In Oracle, stored procedures can return values through output parameters or
as return values of the procedure itself.  If a procedure needs to return
multiple values, it can return one of them as the return value of the procedure
itself, but the rest must be returned through output parameters.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-oracle-testproc-values.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-drop-testproc.sql@
}}}
}}}


==== Sybase and Microsoft SQL Server ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-sybase-testproc-values.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-drop-testproc.sql@
}}}
}}}


==== Firebird ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-firebird-testproc-values.cpp@
}}}
}}}

Alternatively, you can run a query like the following and receive the result
using a output bind variables.  Note that in Firebird, input and
output bind variable indices are distict from one another.  The index of the
first output bind variable is 1 rather than 4, even though there were 3 input
bind variables.

{{{#!blockquote
{{{#!code
@parts/c++-firebird-testproc-values-output-params.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/firebird-drop-testproc.sql@
}}}
}}}


==== DB2 ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-db2-testproc-values.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/db2-drop-testproc.sql@
}}}
}}}


==== Postgresql ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-postgresql-testproc-values.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-drop-testproc-values.sql@
}}}
}}}

==== !MySQL ====

Here's how you can get multiple values from the result
set of a !MySQL procedure.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-values.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-values.cpp@
}}}
}}}

Note: Versions of !MySQL prior to 5.0 had trouble calling stored procedures using bind variables.  If you are using a version of !MySQL prior to 5.0 then SQL relay must fake the bind variables and you must use colon-delimited variables (:1, :2, :3, etc.) in your queries rather than the native-mysql queston marks.

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}

Here's how you can get multiple values from the output variables
of a !MySQL procedure.

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-values-output-params.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-values-output-params.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}



=== Result Sets ===

Some stored procedures return entire result sets.  Below are examples,
illustrating how to create, execute and drop this kind of stored procedure for
each database that SQL Relay supports.

==== Oracle ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-create-testproc-result-set.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-oracle-testproc-result-set.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/oracle-drop-testproc-result-set.sql@
}}}
}}}


==== Sybase and Microsoft SQL Server ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-create-testproc-result-set.sql@
}}}
}}}

To exceute the stored procedure from an SQL Relay program, ue code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-sybase-testproc-result-set.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/sybase-drop-testproc.sql@
}}}
}}}


==== Firebird ====

Stored procedures in Firebird can return a result set if a
select query in the procedure selects values into the output parameters and
then issues a suspend command, however SQL Relay doesn't currently support
stored procedures that return result sets.

==== DB2 ====

Stored procedures in DB2 can return a result set if the procedure is declared
to return one, however SQL Relay doesn't currently support stored procedures
that return result sets.

==== Postgresql ====

To create the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-create-testproc-result-set.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-postgresql-testproc-result-set.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/postgresql-drop-testproc-result-set.sql@
}}}
}}}

==== !MySQL ====

The result sets of all select statements called within !MySQL stored
procedures (that aren't selected into variables) are returned from the procedure
call.  Though !MySQL stored procedures can return multiple result sets,
currently SQL Relay can only fetch the first result set.

To create the stored procedure which returns a result set, run a query like
the following.

{{{#!blockquote
{{{#!code
@parts/mysql-create-testproc-result-set.sql@
}}}
}}}

To execute the stored procedure from an SQL Relay program, use code like the
following.

{{{#!blockquote
{{{#!code
@parts/c++-mysql-testproc-result-set.cpp@
}}}
}}}

To drop the stored procedure, run a query like the following.

{{{#!blockquote
{{{#!code
@parts/mysql-drop-testproc.sql@
}}}
}}}





[=#caching]
== Caching The Result Set ==

Say you're writing a web-based report where a query with a huge result set
is executed and 20 rows are displayed per page.  Rather than rerunning the 
query for every page every time and dumping all but the 20 rows you want to
display, you can run the query once, cache the result set to a local file and
just open the file for each page of the report.

First page:

{{{#!blockquote
{{{#!code
@parts/perl-caching-firstpage.pl@
}}}
}}}

Second page:

{{{#!blockquote
{{{#!code
@parts/perl-caching-secondpage.pl@
}}}
}}}


[=#suspending]
== Suspending and Resuming Sessions ==

Sometimes web-based applications need a single database transaction to span
multiple pages.  Since SQL Relay sessions can be suspended and resumed, this
is possible.

First page:

{{{#!blockquote
{{{#!code
@parts/perl-suspend.pl@
}}}
}}}

Second page:

{{{#!blockquote
{{{#!code
@parts/perl-resume.pl@
}}}
}}}

You can also distribute the processing of a result set across a series of
pages using suspended sessions.  If you're buffering a result set in chunks
instead of all at once and suspend a session, when you resume the session you 
can continue to retrieve rows from the result set.

Similarly, if you're buffering a result set in chunks, caching that
result set and suspend your session.  When you resume the session, you can
continue caching the result set.  You must use resumeCachedResultSet()
instead of resumeResultSet() however.

[=#lastinsertid]
== Getting the Last Insert ID ==

Databases with autoincrement or identity columns often provide functions which return the "last insert id"; the value of the autoincrement column that was generated during the insert into the database.

SQL Relay provides the SQLRelay::Connection::getLastInsertId() method to get this value.

When using the SQLite database, you can also get the last insert id by running the query:

{{{#!blockquote
'''select last insert rowid'''
}}}
