> A DDL statement doesn't take effect until it is committed. At
> commit, the engine performs a lot of stuff to realise the new
> structure, INCLUDING writing records into a number of system tables
> (RDB$RELATION_FIELDS, RDB$FIELDS and others). If the DDL work is
> uncommitted, this stuff isn't visible to the transaction.
>
> THAT IS WHY YOU SHOULD NEVER PERFORM DDL AND DML IN THE SAME

TRANSACTION !!!


I hear you loud and clear, Helen. Won't try that again.

> Don't consider going there. IBO doesn't support nested transactions
> because Firebird and InterBase don't support them. Savepoints are a

I guess I was confused. In the section of your book called "Nested
Transactions" you state "User savepoint statements, also known as
nested transactions, enable you to..." IAC, I won't mess with
savepoints until I know what I'm doing, and won't try them from within
IBO.

> But be aware that deploying a user application as a hands-free way to
> modify the database structure is not to be considered lightly. You
> can make 255 changes to any particular table in the life of a

Got it. I do this neither lightly nor often. I wound up taking a cue
from IBExpert by ensuring that all values are not null, then updating
the RDB$NULL_FLAG in RDB$RELATION_FIELDS. (Hope this doesn't make you
cringe.)


Many thanks for your help-
-David