But I WERE inside the same transaction when I dropped, recreated and
added the primary key to my table. After doing that, the transaction
is committed and subsequent operations are performed on fully visible
objects, so where's my mistake?

Look again at the second script: it drops a table, creates a table
with the same name (but it's a new one inside this transaction, 'cause
a while ago we dropped the old one) and adds a primary key to that new
table, then it commits the changes. What's wrong with it?

It seems that Firebird "confuses" the old (dropped) and the new (just
created) tables, adding the primary key in some way on the old table
and leaving the new one untouched, although the new one reports to
have its primary key (but actually it's not true).

Regards,
Bozzy.

--- In firebird-support@yahoogroups.com, "mikcaau" <macomp@s...> wrote:

> Well of course this is the way that databases work. Until you commit
> your work only objects inside your transaction can see the results of
> them.
> I understand that it is a big mistake to modify a database structure
> whilst other users are connected.
> I could easily imagine dropping a column that someone else is editing
> or adding a new constraint.
>
> Mick