Subject | Re: [firebird-support] Definig variable as a domain |
---|---|
Author | Randall Sell |
Post date | 2010-03-17T07:00:02Z |
________________________________
From: Nando Dessena <nando@...>
To: firebird-support@yahoogroups.com
Sent: Mon, 15 March, 2010 7:01:36 PM
Subject: Re: [firebird-support] Definig variable as a domain
Randall,
R> Exception: validation error for variable RATE, value
R> "10.00000000000000" At procedure 'P_TAX_AMOUNT' line: 11, col: 3
apart from the workaround Helen has suggested, have you tried setting
a DEFAULT value for the RATE variable (or the PERCENTAGE domain), or
otherwise initializing the RATE variable? I think your procdure should
work, but I also think using a SP in a check constraint is a
borderline situation and that might be the source of your error
message.
I'm not using a SP within a check constraint. I am using a SP to derive a computed column. But I didn't try your suggestion as it logically does not make sense to define a default value. What has me scratching my head is that even though the results of the query that are stuck into the variable are valid, as far as the domain's constraints go, why then is it still complaining? And why does it work if the SP is called directly but not via a select that returns that computed column?
Only the FB God's know... All I know, is that I will do it the way FB likes in the future.
-randall
[Non-text portions of this message have been removed]
From: Nando Dessena <nando@...>
To: firebird-support@yahoogroups.com
Sent: Mon, 15 March, 2010 7:01:36 PM
Subject: Re: [firebird-support] Definig variable as a domain
Randall,
R> Exception: validation error for variable RATE, value
R> "10.00000000000000" At procedure 'P_TAX_AMOUNT' line: 11, col: 3
apart from the workaround Helen has suggested, have you tried setting
a DEFAULT value for the RATE variable (or the PERCENTAGE domain), or
otherwise initializing the RATE variable? I think your procdure should
work, but I also think using a SP in a check constraint is a
borderline situation and that might be the source of your error
message.
I'm not using a SP within a check constraint. I am using a SP to derive a computed column. But I didn't try your suggestion as it logically does not make sense to define a default value. What has me scratching my head is that even though the results of the query that are stuck into the variable are valid, as far as the domain's constraints go, why then is it still complaining? And why does it work if the SP is called directly but not via a select that returns that computed column?
Only the FB God's know... All I know, is that I will do it the way FB likes in the future.
-randall
[Non-text portions of this message have been removed]