Martijn Tonies wrote:

> If you cannot change the domain, what is the use of this feature in
> the first place? I mean, isn't the use of domains in SPs meant to
> keep things the same (datatypes) if you change the domain. Heck,
> this is the use for it in the tables, right?

I will explain only once more.
- Currently, a procedure and a table can go out of sync because they can't
share a domain.
- Handling domains with full properties for now in procs is no lightweight
task and not well agreed.
- Therefore, we resort to BASED ON, that will take the data type only. We
will use this stripped domain in procedures and triggers.

Currently, you can change the domain for a table and the procedures using it
won't notice and therefore, there's no chance to stop the change.

With the first implementation, we provide three features:
- Programmer doesn't have to remember the exact data type to declare
variables or parameters. Only the "surrogate" domain's name (I used
"surrogate" because people seem to love surrogate keys, an aberration I've
always disliked, but I concede they may have some enhancement in performance
and also cure the problems with dates as PK's).
- Code is self-documented.
- Maybe your table has 30 fields and only two of them are used in
procedures. Then, if you attempt to change any of those two fields, the
engine will raise a red flag.

To handle automatic cascading of changes, we have to discuss automatic
recompilation or invalidation, a subject that never has been discussed to
reach a full solution. So, for now, I'm happy if the engine allows me to
keep the consistency. Think of it like not being able to change a PK because
there's a FK pointing to it.

C.