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