# 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
    ij> CREATE INDEX i1 ON mytable(mycol);
    0 rows inserted/updated/deleted
    -- p1 is temporarily invalidated because of new index
    ij> execute p1;
    1 row inserted/updated/deleted
    -- Derby  automatically recompiles p1 and executes it
    ij> DROP TABLE mytable;
    0 rows inserted/updated/deleted
    -- Derby  permits you to drop table
    -- because result set of p1 is closed
    -- however, the statement p1 is temporarily invalidated
    ij> CREATE TABLE mytable (mycol INT);
    0 rows inserted/updated/deleted
    ij> INSERT INTO mytable VALUES (1), (2), (3);
    3 rows inserted/updated/deleted
    ij> execute p1;
    1 row inserted/updated/deleted
    -- Because p1 is invalid, Derby  tries to recompile it
    -- before executing.
    -- It is successful and executes.
    ij> DROP TABLE mytable;
    0 rows inserted/updated/deleted
    -- statement p1 is now invalid,
    -- and this time the attempt to recompile it
    -- upon execution will fail
    ij> execute p1;
    ERROR 42X05: Table/View 'MYTABLE' does not exist.

Parent topic: Statements
Related concepts
CREATE statements
DROP Statements
RENAME statements
SET statements
Related reference
ALTER TABLE statement
GRANT statement
REVOKE statement
CALL (PROCEDURE)
CONSTRAINT clause
DECLARE GLOBAL TEMPORARY TABLE statement
DELETE statement
FOR UPDATE clause
FROM clause
GROUP BY clause
HAVING clause
INNER JOIN
INSERT statement
JOIN operation
LEFT OUTER JOIN
LOCK TABLE statement
ORDER BY clause
Query
RIGHT OUTER JOIN
ScalarSubquery
SelectExpression
SELECT statement
TableExpression
TableSubquery
UPDATE statement
VALUES expression
WHERE clause
WHERE CURRENT OF clause