It just hit me that the reason why we need to have those awkward
work-arounds involving GEN_ID's is that the NOT NULL for the primary key is
treated as a prior (Pre) condition before the operation
(insert/update/delete) is performed, but if you come to think of it, the
semantics is really a Post condition (meaning, please guarantee that the ID
is not null after the operation). The same goes for CHECK conditions. [or
maybe it is the client-side fault]

Before <operation> triggers enable IB to revise new.values. Therefore, if
these condition checks are placed after the event (as guarantors) then, we
don't need those awkward execute procedures or IF (new.ID is null OR new.ID
is 0) checks just to get the ID's right.

Also, object-oriented design has realized that there are two condition
checks:
1. Before the operation, so as to free the actual operation from those
awkward value checks
2. After the operation to guarantee that the values produced are in the
satisfactory state.

But currently, I think IB only has the PRE condition and the POST conditions
are to be implemented in triggers. But the not-so-nice thing is, if you
observe, most CHECK constraints are actually POST conditions, but are
evaluated before the operation.

As the OO gurus say, value checking are among the major sources of confusing
code. Thus, the PRE and POST conditions.

Maybe, Interbase can incorporate into SQL, also the PRE conditions and POST
conditions instead of just PRE conditions.

Joseph Alba
jalba@...