| Subject | Re: [IBO] Exception encountered during Drop Table encountered on subsequent operations |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-04-04T23:36:15Z |
At 08:01 AM 5/04/2008, you wrote:
Basically,
1. Never NEVER try to mix DDL and DML in the same transaction
2. Separate each DDL operation in its own transaction....HOWEVER....if you have DDL operations that depend on one another, put them in a TIB_Script and build in proper exit strategies for each statement.
3. Always use explicit transactions for DDL operations.
4. Don't try to design applications that create and destroy metadata unless you understand fully what exceptions it's likely to cause. With that knowledge in your head, write code that will intercept each possible exception and branch the workflow to prevent getting into the state (as here) where the application hasn't a clue where it's at.
(Oh, and that doesn't actually say it's OK to allow your application to get into a clueless state with DML and hope that the Benevolent Gods will intervene...)
Helen
>Hello everyone,Yes
>We are encountering behavior which was not expected after a failed attempt to drop a table. When an exception occurs during a "drop table", it appears that that exception is re-raised on subsequent operations...even if they are not related to the table responsible for the original exception.
>
>Here is a contrived scenario that might occur within our application:
>
>#1. "Drop Table TABLE1" <----Assume this fails because a view exists referencing a column in this table
>
>#2. "Insert Into TESTTABLE2 (SEQ) VALUES(12345)" <----This should execute...but...we receive the same exception that we received in #1
>
>Can someone tell me if this is expected behavior
> and if so..what has to be done after #1 before subsequent database operations can execute ? We are using IBO 4.8.7 and FireBird 2.0.3.Rollback the transaction that has excepted.
Basically,
1. Never NEVER try to mix DDL and DML in the same transaction
2. Separate each DDL operation in its own transaction....HOWEVER....if you have DDL operations that depend on one another, put them in a TIB_Script and build in proper exit strategies for each statement.
3. Always use explicit transactions for DDL operations.
4. Don't try to design applications that create and destroy metadata unless you understand fully what exceptions it's likely to cause. With that knowledge in your head, write code that will intercept each possible exception and branch the workflow to prevent getting into the state (as here) where the application hasn't a clue where it's at.
(Oh, and that doesn't actually say it's OK to allow your application to get into a clueless state with DML and hope that the Benevolent Gods will intervene...)
Helen