At 02:07 PM 6/7/01 +0200, Ivan Prenosil wrote:

>> How would it be to have an extension to the DDL syntax to avoid an

exception

>> if a DROP statement is executed and the object to be dropped is already
>> gone?
>
>
>i.e. implement interpreting few extra commands (on client), like
>SET ON_ERROR {CONTINUE | REPORT | [COMMIT | ROLLBACK] EXIT };
>IF FAILED GOTO Jim's_Label;
>

Ouch. That was my tail be tweaked.

Something that I've done in Netfrastructure that has worked out
spendidly in Netfrastructure is an "upgrade" verb:

upgrade table mathemagica.MMIS (
MMI_ID integer not null primary key,
NAME varchar (60),
DESCRIPTION clob searchable,
MMI clob)

Upgrade created the object if it doesn't exist, otherwise transforms
it in a more or less compatible way (fields aren't actually deleted,
and strings only get longer). The "workbench" utility morphs the
standard JDBC metadata into an upgrade statement (above is example)
which the db designer tweaks incrementally.

Since "upgrade" does what I want, I've never had the need for a
conditional delete (I assume the conditional delete is in preparation
for an unconditional create -- is this correct?). If I wanted a
conditional delete, I'd be tempted to use a second major verb,
say "purge" to get rid of something if it exists and otherwise
get on with life. If, indeed, the main purpose of a conditional
delete was to pave the way for an unconditional create, I'd skip
the exercise altogether and do "upgrade" instead.

Now, back to the tweak. Not very surprisingly, I have very
strong opinions on exception handling. SQL, of course, requires
the programmer to check the SQLDA after every call. Some always
do, most don't. Many, many system failures are the result of
programmers neglecting to check the miserable status code. To
avoid that particular elephant pit, I designed the original
GDML embedded language so any error would blow away the host
program unless the programmer supplied an 'ON_ERROR" clause
to handle it. Correspondingly, it was critical that control
information, e.g. end of record stream, never be returned using
the error channel (the status vector).

JDBC, with my enthusiastic approval, follows the same philosophy.
No global status variables, control information returned as
function values, and exceptions signalled. Like GDML, JDBC
requires with explicit exception handling or program death
(admittedly, Java makes it difficult to avoid the exception
handler).

I'm on-record as believing that the Firebird trigger/procedure
language should be Java. But short of that, language extensions
to be culturally compatible with that end, which dictates
some sort of explicit exception handling and avoidance of
magic variables.

And, of course, no "goto"s.

Jim Starkey