|Subject||Re: [firebird-support] Re: FB 1.5.x CS on Linux - Primary Key FAILURE|
> > > You must apply DML to committed DDL objects. Weird things happen when
> > > mess about as you did, with metadata ghosts hanging around in anis
> > > 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,
> daft. But it wasn't designed that way. It was designed to run DDLNot everyone uses "isql" these days. It's good that isql might start
> 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.
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 withHuh, why not? *g*
> 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.
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL