= Programming with SQL Relay using the Perl DBI API =

* [#session Establishing a Session]
* [#query Executing Queries]
* [#commit Commits and Rollbacks]
* [#temptables Temporary Tables]
* [#errors Catching Errors]
* [#bindvars Bind Variables]
* [#rebinding Re-Binding and Re-Executing]
* [#fields Accessing Fields in the Result Set]
* [#largeresultsets Dealing With Large Result Sets]
* [#statements Statements]
* [#columns Getting Column Information]
* [#storedprocedures Stored Procedures]
* [#lastinsertid Getting the Last Insert ID]
* [#driverspecific Driver-Specific Attributes]

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

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

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

The following connect string variables control attributes of the connection:


* '''host''' - The SQL Relay server to connect to.
* '''port''' - The port that the SQL Relay server is listening on.  Either port or socket must be specified.  If both are specified, socket will be preferred to port.
* '''socket''' - The socket that the SQL Relay server is listening on.  Either port or socket must be specified.  If both are specified, socket will be preferred to port.
* '''tries''' - If a connection fails, it will be retried this many times.
* '''retrytime''' - If a connection fails, it will be retried on this interval (in seconds).
* '''db''' - The database to switch to when logging into SQL Relay.  May be left empty or omitted to accept the default database that SQL Relay is already connected to.
* '''debug''' - If this is set to 1 or to a file name then debug is enabled.  If set to a file name then debug will be written to the file.  If set to 1 then debug will be written to standard output.  Defaults to 0.
* '''lazyconnect''' - By default, the SQL Relay client does "lazy connects".  I.e. the connection to the SQL Relay server isn't established until the first query or other operation is run.  This optimizes availability of the connection pool but is inconstent with most other database API's.  Setting this parameter to 0 causes the connection to the SQL Relay server to be established immediately and the constructor to fail, returning undef, if the connection cannot be established.  Defaults to 1.

In addition, the following connect string variables can be used to establish Kerberos or Active Directory encryption and authentication with the server:

See the [../admin/configguide.html#krb SQL Relay Configuration Guide] for more information about Kerberos and Active Directory configurations.  In particular, user and password are not typically used when using Kerberos/AD.

* '''krb''' - Set to '''yes''' to enable Kerberos/AD encryption/authentication or '''no''' to disable it.
* '''krbservice''' - Specifies the Kerberos service name of the SQL Relay server.  If omitted or left empty then the service name "sqlrelay" will be used. "sqlrelay" is the default service name of the SQL Relay server.  Note that on Windows platforms the service name must be fully qualified, including the host and realm name.  For example: "sqlrelay/sqlrserver.firstworks.com@AD.FIRSTWORKS.COM".
* '''krbmech''' - Specifies the Kerberos mechanism to use.  On Linux/Unix platforms, this should be a string representation of the mechnaism's OID, such as: { 1 2 840 113554 1 2 2 }.  On Windows platforms, this should be a string like: Kerberos.  If omitted or left empty then the default mechanism will be used.  Only set this if you know that you have a good reason to.
* '''krbflags''' - Specifies what Kerberos flags to use.  Multiple flags may be specified, separated by commas.  If left empty or NULL then a defalt set of flags will be used.  Only set this if you know that you have a good reason to.  Valid flags include: GSS_C_MUTUAL_FLAG, GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG, and GSS_C_INTEG_FLAG.  For a full list of flags, consult the GSSAPI documentation, though note that only the previously listed flags are supported on Windows.

The following connect string variables can be used to establish TLS/SSL encryption and authentication with the server:

See the [../admin/configguide.html#tls SQL Relay Configuration Guide] for more information about TLS/SSL configurations.

* '''tls''' - Set to '''yes''' to enable TLS/SSL encryption/authentication or '''no''' to disable it.
* '''tlsversion''' - Specifies the TLS/SSL protocol version that the client will attempt to use.  Valid values include SSL2, SSL3, TLS1, TLS1.1, TLS1.2 or any more recent version of TLS, as supported by and enabled in the underlying TLS/SSL library.  If omittted or left empty then the highest supported version will be negotiated.
* '''tlscert''' - Specifies the file name of the certificate chain file to send to the SQL Relay server.  This is only necessary if the SQL Relay server is configured to authenticate and authorize clients by certificate.
* '''tlspassword''' - If tlscert contains a password-protected private key, then tlspassword may be supplied to access it.  If the private key is not password-protected, then this argument is ignored, and may be omitted or left empty.
* '''tlsciphers''' - Specifies a list of ciphers to allow.  Ciphers may be separated by spaces, commas, or colons.  If omitted or left empty then a default set is used.  For a list of valid ciphers on Linux/Unix platforms, see: man ciphers. For a list of valid ciphers on Windows platforms, see [https://msdn.microsoft.com/en-us/library/windows/desktop/aa375549%28v=vs.85%29.aspx this page].  On Windows platforms, the ciphers (alg_id's) should omit CALG_ and may be given with underscores or dashes.  For example: 3DES_112.  Only set this if you know that you have a good reason to.
* '''tlsvalidate''' - Indicates whether to validate the SQL Relay server's certificate, and may be set to one of the following: '''no''' - Don't validate the server's certificate.  '''ca''' - Validate that the server's certificate was signed by a trusted certificate authority.  '''ca+host''' - Perform "ca" validation and also validate that one of the subject altenate names (or the common name if no SANs are present) in the certificate matches the host parameter.  (Falls back to "ca" validation when a unix socket is used.)  '''ca+domain''' - Perform "ca" validation and also validate that the domain name of one of the subject alternate names (or the common name if no SANs are present) in the certificate matches the domain name of the host parameter.  (Falls back to "ca" validation when a unix socket is used.)
* '''tlsca''' - Specifies the location of a certificate authority file to use, in addition to the system's root certificates, when validating the SQL Relay server's certificate.  This is useful if the SQL Relay server's certificate is self-signed.  On Windows, "ca" must be a file name.  On non-Windows systems, "ca" can be either a file or  directory name.  If it is a directory name, then all certificate authority files found in that directory will be used.  If it a file name, then only that file will be used.

Note that the supported tlscert and tlsca file formats may vary between platforms.  A variety of file formats are generally supported on Linux/Unix platfoms (.pem, .pfx, etc.) but only the .pfx format is currently supported on Windows.


Database handle attributes may be specified in the SQLRelay component of the connect string to control connection and statement behavior.  For example:

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

In addition to the standard database handle attributes (such as AutoCommit, PrintError, etc.), these additional connect string variables control some default statement attributes:

* '''DBD::SQLRelay::ResultSetBufferSize''' - Sets the number of rows to buffer at a time.  See [#largeresultsets Dealing With Large Result Sets] below.  If set to 0 (the default) then the entire result set is buffered.
* '''DBD::SQLRelay::ColumnNameCase''' - Indicates the case to convert column names to.  May be set to "mixed", "upper", or "lower".  Defaults to "mixed".
* '''DBD::SQLRelay::DontGetColumnInfo''' - If this is set to 1 then column info is not fetched with the result set.  If set to 0 then column info is fetched.  Defaults to 0.
* '''DBD::SQLRelay::GetNullsaAsEmptyStrings''' - If this is set to 1 then NULL values are returned as empty strings.  If set to 0 then NULL values are returned as nulls.  Defaults to 0.

Setting one of the statement attribute connect string variables has the same effect as if the corresponding statement handle attribute were set immediately after creating each statement.  See [#driverspecific Driver-Specific Attributes] below.

The other two parameters following the connect string are.

* '''user''' - The username to use when logging into SQL Relay.
* '''password''' - The password to use when logging into SQL Relay.

After calling the constructor, a session is established when the first 
query or other operation is run, unless lazyconnect=0 is used, in which case
a session is established immediately.

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.

[=#query]
== Executing Queries ==

Call prepare() and execute() to run a query.

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

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

If you need to execute a commit or rollback, you should use the commit()
and rollback() methods 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 by setting the AutoCommit attribute
of the database handle.

The following command turns Autocommit on.

{{{#!blockquote
{{{#!code
@parts/perldbi-autocommiton.pl@
}}}
}}}

The following command turns Autocommit off.

{{{#!blockquote
{{{#!code
@parts/perldbi-autocommitoff.pl@
}}}
}}}

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, setting the AutoCommit attribute has 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 calls to connect(), prepare() or execute() fail, you can catch the
error in DBI-&gt;errstr.

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

[=#bindvars]
== Bind Variables ==

Programs rarely execute fixed queries.  More often than not, some part
of the query is dynamically generated.  The Perl DBI API provides means
for using bind variables in those queries.

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

Here is an example using the bind_param() function.  The first parameter of
the bind_param() function corresponds to the name or position of the bind 
variable.

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

The precision and scale parameters can be used to specify a precision
and scale for floating point numbers.

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

You can also bind CLOB's and BLOB's using the DBD::SQLRelay::SQL_CLOB and
DBD::SQLRelay::SQL_BLOB extensions.  When binding a BLOB, you need to pass a
hash containing type and length values.

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

bind_param() is used for input binds.  bind_inout_param() is used for output
binds.  Here is an example using the bind_inout_param() function to retrieve a
value from a query.  The first parameter of a bind_inout_param() call is the
name or position of the bind variable, the second parameter is the local
variable to return the result in and the third variable is the size of the
buffer to reserve for the value.

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

Here is an example using the execute() function directly.  The additional
parameters correspond to bind variable positions.  Note that the first
parameter must be "undef".

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

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

A 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/perldbi-reexecute.pl@
}}}
}}}

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

The fetchrow_array(), bind_columns() and fetch() functions are useful for 
processing result sets.  fetchrow_array() returns an array of values.  
bind_columns() associates variables with columns which are set when fetch() is
called.

Here's an example using fetchrow_array().

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

Here's an example using bind_columns() and fetch().  Note that the first
bind_columns() parameter must be "undef".

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


[=#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.

Perl DBI provides a RowCacheSize database handle attribute to control the
numer of rows to buffer at a time.  This attribute may be specified in the
connect string or as a database handle attribute prior to the execution of a
query.  If left undefined or set to -1 then the entire result set will be
buffered.  If set to 0 then the driver will decide how many rows to buffer.  If
set to a specific number other than 0 or -1 then that many rows will be
buffered.

The statement handle attribute DBD::SQLRelay::ResultSetBufferSize may also
be used to set the number of rows to buffer at a time.  This attribute is a
little more flexible because as a statement handle attribute it can be altered
after prepare but before execute, or in between executes.  It can also be
specified in the connect string.

When buffering the result set in chunks, calls to fetch() 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 set the result set buffer size to 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, fetching row 0 will return false and
fetching row 11 will cause rows 10-14 to be fetched and return the requested
row.

The following code sets the result set buffer size using RowCacheSize in the
connect string.

{{{#!blockquote
{{{#!code
@parts/perldbi-rowcachesize.pl@
}}}
}}}

The following code sets the result set buffer size using RowCacheSize to 5.

{{{#!blockquote
{{{#!code
@parts/perldbi-rowcachesize-set.pl@
}}}
}}}

The following code retrieves the result set buffer size using
RowCacheSize.

{{{#!blockquote
{{{#!code
@parts/perldbi-rowcachesize-get.pl@
}}}
}}}

The following code sets the result set buffer size using ResultSetBufferSize

in the connect string.

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

The following code sets the result set buffer size using ResultSetBufferSize
to 5.

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

The following code retrieves the result set buffer size using
ResultSetBufferSize.

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

[=#statements]
== Statements ==

It's possible to execute new 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/perldbi-reexecute.pl@
}}}
}}}

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

After executing a query, the column count is stored in the NUMBER_OF_FIELDS
statement property and column names are stored in the NAME statement property.
They are accessible as follows:

{{{#!blockquote
{{{#!code
@parts/perldbi-columninfo.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/perldbi-oracle-testproc.pl@
}}}
}}}

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/perldbi-sybase-testproc.pl@
}}}
}}}

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/perldbi-firebird-testproc.pl@
}}}
}}}

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/perldbi-db2-testproc.pl@
}}}
}}}

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/perldbi-postgresql-testproc.pl@
}}}
}}}

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/perldbi-mysql-testproc.pl@
}}}
}}}

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/perldbi-oracle-testproc-1value.pl@
}}}
}}}

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/perldbi-oracle-testproc-1value-output-param.pl@
}}}
}}}

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/perldbi-sybase-testproc-1value.pl@
}}}
}}}

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/perldbi-firebird-testproc-1value.pl@
}}}
}}}

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/perldbi-firebird-testproc-1value-output-param.pl@
}}}
}}}

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/perldbi-db2-testproc-1value.pl@
}}}
}}}

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/perldbi-postgresql-testproc-1value.pl@
}}}
}}}

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/perldbi-mysql-testproc-1value.pl@
}}}
}}}

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/perldbi-mysql-testproc-1value-result-set.pl@
}}}
}}}

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/perldbi-mysql-testproc-1value-output-param.pl@
}}}
}}}

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/perldbi-oracle-testproc-values.pl@
}}}
}}}

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/perldbi-sybase-testproc-values.pl@
}}}
}}}

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/perldbi-firebird-testproc-values.pl@
}}}
}}}

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/perldbi-firebird-testproc-values-output-params.pl@
}}}
}}}

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/perldbi-db2-testproc-values.pl@
}}}
}}}

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/perldbi-postgresql-testproc-values.pl@
}}}
}}}

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/perldbi-mysql-testproc-values.pl@
}}}
}}}

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/perldbi-mysql-testproc-values-output-params.pl@
}}}
}}}

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/perldbi-oracle-testproc-result-set.pl@
}}}
}}}

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/perldbi-sybase-testproc-result-set.pl@
}}}
}}}

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/perldbi-postgresql-testproc-result-set.pl@
}}}
}}}

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/perldbi-mysql-testproc-result-set.pl@
}}}
}}}

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

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






[=#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.

DBI provides the $dbh-&gt;last_insert_id() 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'''
}}}

[=#driverspecific]
== Driver-Specific Attributes ==

Perl DBI allows drivers to define their own attributes for database handles and statements.  These attributes can be set to control various parameters unique to the driver.  SQL Relay implements several of these.

Database handle attributes defined by the SQL Relay driver:

* '''DBD::SQLRelay::Debug''' - set-only (1, 0 or file name), when set to 1, debug is enabled to standard output, when set to 0, debug is disabled, when set to a file name, debug is sent to that file.

Statement handle attributes defined by the SQL Relay driver:

* '''DBD::SQLRelay::ResultSetBufferSize''' - get/set, returns or sets the result set buffer size as described [#largeresultsets above].
* '''DBD::SQLRelay::ColumnNameCase''' - set-only, returns the case that column names will be converted to - "mixed", "upper", or "lower".
* '''DBD::SQLRelay::DontGetColumnInfo''' - set-only (1 or 0), sets whether or not to fetch column info with the result set, default (0) is to return column info
* '''PDO::SQLRelay::GetNullsAsEmptyStrings''' - set-only (1 or 0), sets whether to return NULL values as empty strings or nulls, default (0) is to return NULL values as nulls

Default values for the statement handle attributes can be set as database handle attributes in the connect string.  Setting the corresponding connect string variable has the same effect as if the statement handle attribute were set immediately after creating the statement.  See [#session Establishing a Session] above.
