[ http://issues.apache.org/jira/browse/DERBY-1435?page=all ]
Deepa Remesh updated DERBY-1435:
--------------------------------
Attachment: repro1435_for_functions.sql
A similar case occurs when function/procedure referenced in triggered SQL
statement is dropped and a previously executed statement is re-executed to fire
the trigger. In this case, no exception is thrown; the trigger firing is
successful (executes the function/procedure as if it had not been dropped).
The new repro 'repro1435_for_functions.sql' shows this. Also, I see a different
behaviour in the execution of a statement when it is preceded with a comment.
This is also included in the repro. I am adding this to the same issue as the
problems look similar.
> Conglomerate does not exist occurs in a specific case after dropping a table
> referenced by a trigger
> ----------------------------------------------------------------------------------------------------
>
> Key: DERBY-1435
> URL: http://issues.apache.org/jira/browse/DERBY-1435
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.2.0.0
> Reporter: Deepa Remesh
> Attachments: repro1435.sql, repro1435_for_functions.sql
>
> This exception occurs in the following case:
> 1. Create tables t1 and t2. Create a trigger on t2 whose triggering action is
> to insert a row into t1
> 2. Insert a value v1 into t2. Verify the trigger was fired by looking at
> contents of t1.
> 3. Drop table t1.
> 4. Insert a value v2 into t2. This will give an exception to indicate that
> table t1 does not exist.
> 5. Insert the same value v1 into t2. Instead of the exception in Step 4, this
> gives "ERROR XSAI2: The conglomerate (896) requested does not exist."
> 6. Re-create table t1.
> 7. Insert v2 into t2. This succeeds.
> 8. Try to insert the problem value v1 into t2. This still gives "ERROR XSAI2:
> The conglomerate (896) requested does not exist."
> 9. Shutdown and reconnect to the database. Try to insert the problem value v1
> into t2. Now this succeeds.
> So the exception occurs only in the specific case where we try to insert the
> same value that we had inserted before dropping the table referenced by the
> trigger. I'll attach a sql script to repro this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
