<< cursor-Name | ALTER TABLE statement >>

Interaction with the dependency system

<< cursor-Name | ALTER TABLE statement >>

Derby Reference Manual

Example

DROP ROLE reader

Statements

This section provides manual pages for both high-level language constructs and parts
thereof. For example, the CREATE INDEX statement is a high-level statement that you
can execute directly via the JDBC interface. This section also includes clauses, which
are not high-level statements and which you cannot execute directly but only as part
of a high-level statement. The ORDER BY and WHERE clauses are examples of this
kind of clause. Finally, this section also includes some syntactically complex portions of
statements called expressions, for example

SelectExpression

and

TableSubquery

. These

clauses and expressions receive their own manual pages for ease of reference.

Unless it is explicitly stated otherwise, you can execute or prepare and then execute
all the high-level statements, which are all marked with the word statement, via the
interfaces provided by JDBC. This manual indicates whether an expression can be
executed as a high-level statement.

The sections provide general information about statement use, and descriptions of the
specific statements.

Interaction with the dependency system

Derby internally tracks the dependencies of prepared statements, which are SQL
statements that are precompiled before being executed. Typically they are prepared
(precompiled) once and executed multiple times.

Prepared statements depend on the dictionary objects and statements they reference.
(Dictionary objects include tables, columns, constraints, indexes, views, and triggers.)
Removing or modifying the dictionary objects or statements on which they depend
invalidates them internally, which means that Derby will automatically try to recompile
the statement when you execute it. If the statement fails to recompile, the execution
request fails. However, if you take some action to restore the broken dependency (such
as restoring the missing table), you can execute the same prepared statement, because
Derby will recompile it automatically at the next execute request.

Statements depend on one another-an UPDATE WHERE CURRENT statement depends
on the statement it references. Removing the statement on which it depends invalidates
the UPDATE WHERE CURRENT statement.

In addition, prepared statements prevent execution of certain DDL statements if there are
open results sets on them.

Manual pages for each statement detail what actions would invalidate that statement, if
prepared.

Here is an example using the Derby tool ij:

ij> CREATE TABLE mytable (mycol INT);
0 rows inserted/updated/deleted
ij> INSERT INTO mytable VALUES (1), (2), (3);
3 rows inserted/updated/deleted
-- this example uses the ij command prepare,
-- which prepares a statement
ij> prepare p1 AS 'INSERT INTO MyTable VALUES (4)';
-- p1 depends on mytable;
ij> execute p1;
1 row inserted/updated/deleted
-- Derby executes it without recompiling