At 12:06 PM 16/01/2003 +0200, you wrote:

>Thanks Helen for the reply....it does make sense to me....
>
>One more question, is it a bug (that will or could be fixed), or is it one
>of those things that you learn and hopefully never make the same mistake
>twice????
>

I think it's something people do because they CAN, so in this sense the
database doesn't stop you from shooting yourself in the foot, if you really
want to. It's the kind of trap that "transaction-minded" developers are
possibly less likely to fall into than those whose database background is
with flat-file systems, where the logical and physical aspects of a task
are completed in one hit.

But the more you think about it, the less it makes sense to attempt to
apply data to data structures that don't yet physically exist.

The fact is that, because a client/server RDBMS isn't meant to be
maintained interactively, but through an orderly series of requests
submitted via scripts, having the convenience of *seeming* to be working
interactively through a GUI client is a two-edged sword. Not all GUI tools
make it very obvious that proper transaction control actually *matters*
when you are modifying metadata. If you are used to an interactive
interface for Paradox, Access and so forth, these GUI tools can give you
the false sense that you have the same non-negotiable relationship with Fb/IB.

DDL transactions are separate from DML transactions. With a script, you
can include a SET AUTODLL ON command, to have each DDL command request
issued inside its own discrete transaction. Then, mixing DDL and DML in a
single script can be a rather sensible idea - provided, natch, that you
don't apply data to structures that don't happen until *later* in the
script. <g>

I have to say that, these days, I'm totally paranoid about DDL. I script
*everything*, even ALTER INDEX, I keep DML and DDL separate and I make
liberal use of comments. A lot of this is for the sake of perpetuity so
that I and others can track the development of the way the database
structure developed. It's also a cheap way to do database documentation
and to make use of documentation aids like Time2Help, et al.

Aaah, I think you just got me onto one of my hobby horses here, Stephen.

:-)
heLen