Hi Ann,

--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> Adam,
> >
> >
> > The same way you handle someone trying to put an integer into a
> > varchar field or a string into a timestamp. If I define
> >
> > CREATE DOMAIN TBLID AS INTEGER check( value > 0 ) NOT NULL;
> >
> > And someone tries to use a parameter of -1, then it is an invalid
> > typecast (or whatever the error is). It is as wrong (from a business
> > rules perspective) as trying to insert 'Adam' into such a field.
> > Obviously, just my personal opinion
>
> OK, I'm with you on input. But should the output parameters also be
> constrained (hint, the answer is yes)? OK, but what about intermediate
> results... If the output parameter is not null, can you set it to null
> within the procedure, or does that cause an error?

An extremely valid point and it probably deserves more consideration,
but I agree that the output parameters should be constrained (as well
as internally within the SP etc).

The easiest way to illustrate my reasoning would be a domain like one
we use for our primary key fields (integer > 0 not null). In a
conceptual sense, this field is not an integer. If I say my field is
of this domain type, I am defining a field that only accepts positive
integers and rejects nulls. Therefore NULL should never be accepted as
a valid value in such a field (or hence parameter).

This may be stretching it a bit, but to me it is like arguing that I
should be able to store 'Adam' in an integer parameter, as long as I
replace it with a valid piece of data before I call suspend or my
procedure ends. I mean that although at a logical level, my domain is
simply an integer which internally runs a few more integrity checks
before accepting, at a higher level it is not an integer field. My
domain is simply a field that can hold some subset of the base field type.

> >
> > And what happens to a procedure when the constraint on the
> > domain of one of its parameters changes?
> >
> > I imagine it would have to recompile.
>
> That sounds good, except that procedures can't be recompiled while
> they're running, so the exact mechanism is tricky. Not that it

can't be

> resolved, but that it's non-trivial.

Absolutely, lucky we have so many talented people ;). I do not know
how this can or will be done, but I am sure the solution will be a gem.

> >
> >
> > Thats fine. The work around is pretty simple. ... but I still think
> > that in the long run this will be a very powerful feature.
> >
>
> I agree completely
>

Thanks

Adam