Thanks.
I do now understand the reason.
I guess I'll have a better understanding when I'll read your book,
I've ordered it today :)


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 10:26 PM 7/01/2005 +0000, you wrote:
>
>
> >Hi people,
> >
> >Let's say I have domains defined as:
> >
> >CREATE DOMAIN VC16 AS VARCHAR(16)
> >CREATE DOMAIN MYDATE AS DATE
> >
> >Is there a way that I can do something like this?
> >
> >CREATE PROCEDURE SP_TMP (
> > pFIRST_DATE MYDATE,
> > pLAST_DATE MYDATE
> >)
> >AS
> > DECLARE VARIABLE NAME VC16;
> > DECLARE VARIABLE LASTNAME VC16;
> > BEGIN
> > ..
>
> No.
>
>
> >When I try do create a stored procedure like this, Firebird says it
> >doesn't know anything about MYDATE and VC16. And when I create a
> >stored procedure by typing the full field definitions, it creates

new

> >domains as RDB$4269, RDB$4270, RDB$4271 and so on.. As you see I

have

> >already many domains so wouldn't it be nice if I could reduce some?
> >(I have 162 tables, 151 procedures, 90 users, 3.5gb firebird file)
>
> User-defined domains currently are available only for defining

columns in

> tables.
>
> Domain definitions can be changed. When that happens, the engine

makes the

> required changes to any table column defs that use the domain.

Currently,

> there is no mechanism by which the engine could somehow crawl

inside a

> compiled stored procedure or trigger and validate or update the

object code

> when a domain is changed. SP and trigger objects are also subject

to some

> strong existence restrictions once they have been invoked in a

session.

>
> The idea of making it so that domain definitions are available for

PSQL

> variables is discussed often and is likely to be supported in a

future

> major version of Firebird. It's not something that can be done
> arbitrarily, since it requires a lot of re-architecting under the

hood.

>
> ./hb