Subject RE: [firebird-support] Domains in computed columns
Author Rick Debay
This is what I ended up with. We're using FB 1.5 until 2.1.2 is
released. It will be nice when domains can be used in a CAST.
If I can reproduce it after migrating to 2.1 I'll post a bug. Otherwise
I won't, as minor bug support in 1.5 isn't a priority anymore.

ALTER TABLE MDDB_DRUG
ADD IS_BRAND CHAR(1) /*D_BOOLEAN*/ COMPUTED BY (CAST((CASE WHEN
MULTISRC='Y' THEN 'N' ELSE 'Y' END) AS CHAR(1))),
ADD ATOM_PKG_SZ DECIMAL(8,3) COMPUTED BY (CAST((CASE WHEN ATOM='Y'
THEN PKG_SZ ELSE NULL END) AS DECIMAL(8,3))),
ADD BRAND_NDC9 NUMERIC(9,0) /*D_NDC9*/ COMPUTED BY (CAST((CASE WHEN
MULTISRC<>'Y' THEN PID_CORE9 ELSE NULL END) AS NUMERIC(9,0)))
;

________________________________

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Helen Borrie
Sent: Wednesday, March 04, 2009 5:31 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Domains in computed columns



At 08:42 AM 5/03/2009, you wrote:
>If I define a computed column with an explicit data type, it works:
>
>FIELD_NAME DECIMAL(5,2) COMPUTED BY (...some formula...)
>
>If I use a domain name, I get an error message:
>
>ISC ERROR CODE:335544569
>ISC ERROR MESSAGE:
>Dynamic SQL Error
>SQL error code = -104
>Token unknown - line 21, char 24
>COMPUTED
>
>FIELD_NAME DOMAIN_NAME COMPUTED BY (...some formula...)
>
>
>Is this the expected behavior?

Well, it's surprising that you didn't get an exception in the first
case, since you can't specify the output data type of a computed column.


The second case is entirely as expected. The engine creates its own
domain for the computed column (as it does for real columns in the
absence of a domain specifier) but for obvious reasons it can't be
overridden. As Alexandre pointed out, if you need to force the data type
of the output, you can use a CAST in the expression.

The first case seems to be at least a quirk in the DDL parsing. If it
exists, it might be a carry-over that's been left intentionally so as
not to break legacy DDL in user apps. Other no-ops in the SQL language
have been progressively deprecated and eventually made exceptions. You
might like to post a description and a reproducible example in the
Tracker. If you do, make sure you say which version your observation
applies to.

./heLen

Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.