> x> I imagine that you are talking about how to propagate the domain

changes

> x> to the stored procedures and triggers, isn't it ?
>
> exactly. For example, try to imagine what engine must do
> if you altered domain type that is used in procedure parameters.
>
> Of course, procedure must be recompiled (altered).
> Of course, there can be conversion errors with new
> domain parameter type.
>
> Since server can't compile anything by it's good will,
> and anyway does not how to handle errors during such
> compilation, the only way to allow this is to introduce
> "state" for all objects like in Oracle.
>
> So, with this flag, referenced (dependent) objects can be set as "invalid"
> if some object was altered. If you alter domain, procedure that
> depends on it becomes invalid and can't be called by any user
> until it will be recompiled manually.
>
> In this case your question can be restated to
> "when will be object state implemented, so we can
> move forvard and at long last implement domains as
> procedure parameters?" :-)

And easier updating of objects without dependencies fooling around :-)

Can I vote for "object_state" somewhere??

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com