Hi Alexander,

> > PARAM1 EMPLOYEE.EMPLOYEEDID%TYPE
> >
> > As a param datatype - this also helps a lot. And yes, these
> procedures
> > are compiled as well. But when the EMPLOYEE.EMPLOYEEID
> > column is changed, the procedure is flagged "invalid" and
> automatically
> > re-compiled on the first call
>
> Martijn, it is not so simply in real world - procedures often call
> each other, depth and structure of nested calls can be rather
> large and complicated. Remember now what a headach we have changing
> type of parameters in low-level procedure, especially if this
> parameters pass through significant part of the calls tree. To teach
> server make this automatically is'nt simple task. Remember that
> procedures are often called by triggers which should become invalid
> too. And annoying "object in use"...

"object in use" ... very annoying.

> > or you
> > can have a decent developer-UI that shows you the invalid procedures
> > and let's you recompile/change them.
>
> This is more realistic.
>
> Perhaps discussed feature is really useful, (not sure, I don't use
> domains at all) but IMHO we have more interesting fields for
> developer's activity :)

The reason I'm talking about this again is that it let's you alter
a (series of) procedure(s) without getting dependency errors -
as long as you leave the database in a consistent state.

Currently, when you try to adjust a view, you run in all sorts of
troubles - if this view is used in other views, procedures etc...


With regards,

Martijn Tonies
Database Workbench - the developer tool for InterBase & Firebird
Upscene Productions
http://www.upscene.com