>
> > > You must apply DML to committed DDL objects. Weird things happen when

you

> > > mess about as you did, with metadata ghosts hanging around in an
> > > uncommitted transaction. >>>"As designed".<<<
> >
> >"weird things" as designed?
> >
> >I would call "raising an error" as designed, but not "weird things"
>
> It would, if it were *designed* to raise an error when you do something
> that, in SQL terms, isn't disallowed but that, in terms of common sense,

is

> daft. But it wasn't designed that way. It was designed to run DDL
> statements in autoDDL by default.
>
> >:-)
> >
> >
> >But hey, we discussed this in fb-devel. No results yet though.
>
> No "results" even proposed, really. Most agree *something* needs to be
> done to prevent "silly" scripts from continuing to execute; but it's
> another of these cases where, by stopping careless people from doing silly
> things, you have to also stop careful people from doing things that are
> entirely reasonable.

Not everyone uses "isql" these days. It's good that isql might start
another transaction for DML, but lots of other tools don't.

So, IMO, the first step would be, when executing DML in the
same transaction as an uncommitted DDL change to objects
involved in the DML statement, would raise an exception. Currently,
this doesn't happen.

> Until there is some solution that works for everyone, I'll just stick with
> advising people to use isql in the way it was designed to be used and to
> expect weird things back when you throw weird things at it. Same as I
> advise people not to use the microwave as a hairdryer for puppies.

Huh, why not? *g*

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com