Subject | Re: [firebird-support] How to use a Domain in a Stored Procedure or Trigger? |
---|---|
Author | Jacqui Caren |
Post date | 2004-08-07T11:11:04Z |
Lester Caine wrote:
My understanding of the original request was that when creating a
trigger against a table which uses domains, you are stuck with
having to expand each domain when creating the triggers for this
table.
Allowing the OP's use of domains in declare variable statements
would make code management far simpler.
Instead, I and other resport to hacks such as
CREATE TRIGGER "TRIG_MY_TABLE_AI" FOR "MY_TABLE" AFTER INSERT AS
DECLARE VARIABLE pID INTEGER; /* DOMAIN: TID */
...
and use a perl script to 'expand/replace' the domain definitions
using the DOMAIN: comment.
Being able to use domains would eliminate this "smelly hack".
Even better, something similar to oracle
declare variable pID MYTABLE.PID%TYPE;
Eliminates the possibility that you get the domain wrong.
Looking up the type/precision/scale etc for a table.field
is not exactly hard - I do it in some stored procedures
for some generic cast to blob (st1) code.
Jacqui
>>>how do I use a Domain in a Stored Procedure or Trigger?What has this to do with the original question?
>>
>>You cannot.
>
>
> You would not normally create tables in a Stored Procedure. Just run a
> script - which you could store in a BLOB in the database ;)
My understanding of the original request was that when creating a
trigger against a table which uses domains, you are stuck with
having to expand each domain when creating the triggers for this
table.
Allowing the OP's use of domains in declare variable statements
would make code management far simpler.
Instead, I and other resport to hacks such as
CREATE TRIGGER "TRIG_MY_TABLE_AI" FOR "MY_TABLE" AFTER INSERT AS
DECLARE VARIABLE pID INTEGER; /* DOMAIN: TID */
...
and use a perl script to 'expand/replace' the domain definitions
using the DOMAIN: comment.
Being able to use domains would eliminate this "smelly hack".
Even better, something similar to oracle
declare variable pID MYTABLE.PID%TYPE;
Eliminates the possibility that you get the domain wrong.
Looking up the type/precision/scale etc for a table.field
is not exactly hard - I do it in some stored procedures
for some generic cast to blob (st1) code.
Jacqui