Randall,

R> apart from the workaround Helen has suggested, have you tried setting
R> a DEFAULT value for the RATE variable (or the PERCENTAGE domain), or
R> otherwise initializing the RATE variable? I think your procdure should
R> work, but I also think using a SP in a check constraint is a
R> borderline situation and that might be the source of your error
R> message.

R> I'm not using a SP within a check constraint. I am using a SP to
R> derive a computed column.

My bad. I actually meant a computed column.

R> But I didn't try your suggestion as it
R> logically does not make sense to define a default value. What has
R> me scratching my head is that even though the results of the query
R> that are stuck into the variable are valid, as far as the domain's
R> constraints go, why then is it still complaining? And why does it
R> work if the SP is called directly but not via a select that returns that computed column?

my guess was that the first query in your SP would not return any rows
in some cases, which would let the RATE variable with an undefined
value (you might or might not know that local variables in PSQL are
not automatically inizialized). About the difference between using a
domain with or without the TYPE OF keywords, it's explained in the
release notes Helen has pointed you to in an earlier message.

HTH
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================