88 lines
6.8 KiB
HTML
88 lines
6.8 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="concept" />
|
||
|
<meta name="DC.Title" content="PreparedStatements" />
|
||
|
<meta name="abstract" content="PreparedStatements extend the Statement interface and provide support for adding parameters to SQL statements." />
|
||
|
<meta name="description" content="PreparedStatements extend the Statement interface and provide support for adding parameters to SQL statements." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="statetyp.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="statemnt.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="callable.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="prepcreate.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="prepproc.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="prepex.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="prepstat" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>PreparedStatements</title>
|
||
|
</head>
|
||
|
<body id="prepstat"><a name="prepstat"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">PreparedStatements</h1>
|
||
|
<div><p>PreparedStatements extend the Statement interface and provide support
|
||
|
for adding parameters to SQL statements.</p>
|
||
|
<p>SQL statements that are passed to the database go through a two-step process
|
||
|
in returning results to you. They are first prepared and then are processed.
|
||
|
With Statement objects, these two phases appear to be one phase to your applications.
|
||
|
PreparedStatements allow these two steps to be broken apart. The preparation
|
||
|
step occurs when the object is created and the processing step occurs when
|
||
|
the executeQuery, executeUpdate, or execute method are called on the PreparedStatement
|
||
|
object.</p>
|
||
|
<p>Being able to split the SQL processing into separate phases are meaningless
|
||
|
without the addition of parameter markers. Parameter markers are placed in
|
||
|
an application so that it can tell the database that it does not have a specific
|
||
|
value at preparation time, but that it provides one before processing time.
|
||
|
Parameter markers are represented in SQL statements by question marks.</p>
|
||
|
<p>Parameter markers make it possible to make general SQL statements that
|
||
|
are used for specific requests. For example, take the following SQL query
|
||
|
statement:</p>
|
||
|
<pre> SELECT * FROM EMPLOYEE_TABLE WHERE LASTNAME = 'DETTINGER'</pre>
|
||
|
<p>This is a specific SQL statement that returns only one value; that is,
|
||
|
information about an employee named Dettinger. By adding a parameter marker,
|
||
|
the statement can become more flexible:</p>
|
||
|
<pre> SELECT * FROM EMPLOYEE_TABLE WHERE LASTNAME = ?</pre>
|
||
|
<p>By simply setting the parameter marker to a value, information can be obtained
|
||
|
about any employee in the table.</p>
|
||
|
<p>PreparedStatements provide significant performance improvements over Statements
|
||
|
because the previous Statement example can go through the preparation phase
|
||
|
only once and then be processed repeatedly with different values for the parameter.</p>
|
||
|
<div class="note"><span class="notetitle">Note:</span> Using PreparedStatements is a requirement to support the native JDBC
|
||
|
driver's statement pooling.</div>
|
||
|
<p>For more information about using prepared statements, including creating
|
||
|
prepared statements, specifying result set characteristics, working with auto-generated
|
||
|
keys, and setting parameter markers, see the following pages:</p>
|
||
|
</div>
|
||
|
<div>
|
||
|
<ul class="ullinks">
|
||
|
<li class="ulchildlink"><strong><a href="prepcreate.htm">Create and use PreparedStatements</a></strong><br />
|
||
|
The prepareStatement method is used to create new PreparedStatement objects. Unlike the createStatement method, the SQL statement must be supplied when the PreparedStatement object is created. At that time, the SQL statement is precompiled for use.</li>
|
||
|
<li class="ulchildlink"><strong><a href="prepproc.htm">Process PreparedStatements</a></strong><br />
|
||
|
Processing SQL statements with a PreparedStatement object is accomplished with the executeQuery, executeUpdate, and execute methods like Statement objects are processed. Unlike Statement versions, no parameters are passed on these methods because the SQL statement was already provided when the object was created. Because PreparedStatement extends Statement, applications can attempt to call versions of executeQuery, executeUpdate, and execute methods that take a SQL statement. Doing so results in an SQLException being thrown.</li>
|
||
|
<li class="ulchildlink"><strong><a href="prepex.htm">Example: Use PreparedStatement to obtain a ResultSet</a></strong><br />
|
||
|
This is an example of using a PreparedStatement object's executeQuery method to obtain a ResultSet.</li>
|
||
|
</ul>
|
||
|
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="statetyp.htm" title="The Statement interface and its PreparedStatement and CallableStatement subclasses are used to process structured query language (SQL) commands against the database. SQL statements cause the generation of ResultSet objects.">Statement types</a></div>
|
||
|
</div>
|
||
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
<div><a href="statemnt.htm" title="A Statement object is used for processing a static SQL statement and obtaining the results produced by it. Only one ResultSet for each Statement object can be open at a time. All statement methods that process an SQL statement implicitly close a statement's current ResultSet if an open one exists.">Statements</a></div>
|
||
|
<div><a href="callable.htm" title="The CallableStatement interface extends PreparedStatement and provides support for output and input/output parameters. The CallableStatement interface also has support for input parameters that is provided by the PreparedStatement interface.">CallableStatements</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|