At 04:47 AM 6/04/2007, you wrote:

>Hi All -
>
>One of my beta testers is seeing a very strange problem reading fixed
>point data from a Firebird 2.0 server: the data appears to be being
>scaled twice. The field is a DECIMAL(15,4) domain, but when I query
>the rdb$field_precision, I get -1. The user did not create the
>database (it is built by a third party application) so we have to
>rely on querying the metadata tables to find out about the data
>structure. We are using identical FB server versions (2.0 final).
>
>A few questions:
>
> - Under what conditions should I ignore the XSQLVAR.sqlscale
>member? Is it only correct for integer types (SQL_SHORT, SQL_LONG,
>SQL_QUAD and SQL_INT64) or should I be using it with the floating
>point types as well?
>
> - What causes a precision of -1 to be entered into rdb$fields.rdb
>$field_precision?
>
> - We have tried using the following DDL to recreate the problem at
>my end with no luck (the user cannot share the database file):
>
>CREATE DOMAIN T_AMOUNT AS NUMERIC(15,4);
>
>CREATE TABLE B11231 (
> ID INTEGER NOT NULL,
> TOTAL_PRICE T_AMOUNT default 0
>);
>COMMIT;
>
>This appears to yield identical show domain/show table results as the
>user's machine, but not identical behaviour. What queries can I run
>on his machine to get a better idea of how to replicate this domain
>on my development machine?

Hmmm, something is amiss there that you don't know
about. RDB$FIELD_PRECISION should never be negative for a fixed
numeric type. A decimal(15,4) in dialect 3 would have precision of
18; in D1 it would be a DOUBLE PRECISION, since D1 doesn't support
fixed numerics with > 9 digits of precision. Ask for a metadata-only
backup and see what's really going on (including the
dialect). However, restoring the metadata-only backup won't give the
answer if it's an ODS9 database that has been restored to ODS 10 or
higher...you'd need the data, since it's likely that the restore has
simply written the precision for those doubles as -1, due to their
being neither one thing nor the other under the higher ODS.

Note, too, that the XSQLVAR.sqlscale member returns RDB$FIELD_SCALE,
not RDB$FIELD_PRECISION...

./heLen