Watch, Follow, &
Connect with Us

Please visit our new home

Public Report
Report From: InterBase/Interfaces/SQL/Stored Procedures    [ Add a report in this area ]  
Report #:  4306   Status: Open
Allow usage of Domains in SPs/Triggers
Project:  InterBase Build #:  7.0.1
Version:    7.0 Submitted By:   Karsten Strobel
Report Type:  New Feature Request Date Reported:  5/5/2003 1:31:57 AM
Severity:    Commonly encountered problem Last Updated: 3/20/2012 2:24:39 AM
Platform:    Not OS or platform specific Internal Tracking #:   141850
Resolution: None (Resolution Comments) Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (7 Total Ratings)
4.71 out of 5
Total Votes: 26
I understand that making domain types available in SPs and Triggers is not trivial, because this would require to introduce checks, defaults and type altering capabilities here. In order to allow users to take some advantage from domains though, I'd like to propose to support a simple macro that accesses the native base type of a domain where a sp parameter or local var is defined. Could look like this:

Steps to Reproduce:
From borland.private.fieldtest.shaka

Karsten Strobel wrote:

I'd like to be able to use domains in declaration of stored procedure
variables and local variable (also in triggers). I know that this is hard
to do, as a domain can be altered. In my practise, I did not ever alter
one domain. I rather use them to make the code better readable (declaring
dBoolean SMALLINT CHECK ... f r example). So it would be no problem from
my point of view, to restrict the ability of domains being altered to
cases where they're not used in procedures/triggers. Also, it would be
fine for me to introduce a "STATIC" attribute for domains that make them
unchangeable, but that would allow me to use them in sp.


Craig Stuntz wrote:

It's more than that.  DOMAINs can contain DEFAULTs and CHECKs, as


Martijn Tonies wrote:

Hmmm... Check constraints are also useful while processing in a stored
procedure - for example, it would make them range-checking variables.

VALUE >= 0

Now, when a value is assigned to it that violates the CHECK constraint -
an exception can be raised. Neat - it allows you to check data values
while processing inside procs...

Wayne Niddery wrote:

That's fine. Now how about a domain (called mydomain for demonstration) with
a not null constraint but no default value? What should IB do when
confronted with:

declare variable x: mydomain; ??

I'm also in favour of being able to use domains in procs and triggers - I'd
love it, but these things have to be handled. In this example, the only
thing I can think to do is to extend declare variable  to allow an initial

declare variable x: mydomain = 100;

...and then enforce this as a requirement in the case of such domains.


Server Response from: ETNACODE01