Re: [SQL] [JDBC] Error in DatabaseMetaData.getColumns() with Views

[Dario V. Fassi]

kris, Next you can see how the same test-case is handled by DB2. -- IBM DB2 V6.1 for Linux CREATE TABLE userid.t (  f1 numeric(6,3),  f2 numeric(6,4),  f3 numeric(8,2) ); create view userid.v as select (f1+f2+f3) as fsum, coalesce(f1,f2,f3) as fcoal, (f1*f2*f3) as fprod, (f1/f2) as fdiv from userid.t; insert into userid.t values ( 123.123, 12.1234, 12345.12); insert into userid.t values ( null, 12.1234, 12345.12); insert into userid.t values ( 123.123, null, 12345.12); insert into userid.t values ( 123.123, 12.1234, null); insert into userid.t values ( 999.999, 99.9999, 99999.99); select * from userid.v  FSUM        | FCOAL    | FPROD                | FDIV                        | ------------------------------------------------------------------------------  12480.3664  | 123.1230 | 18427182.594204384   | 10.155814375505221307553986 | ------------------------------------------------------------------------------              | 12.1234  |                      |                             | ------------------------------------------------------------------------------              | 123.1230 |                      |                             | ------------------------------------------------------------------------------              | 123.1230 |                      | 10.155814375505221307553986 | ------------------------------------------------------------------------------  101099.9889 | 999.9990 | 9999979000.011999999 | 10.000000000000000000000000 | ------------------------------------------------------------------------------ METADATA RETURNED BY DatabaseMetaData.getColumns() Tabla: USERID.V #      Campo          Tipo          Anulable ReadOnly Writable AutoInc CaseSens Currency 1     FSUM [0]        DECIMAL(11,4)  . . WA . . . 2     FCOAL [0]       DECIMAL(10,4)  . . WA . . . 3     FPROD [0]       DECIMAL(20,9)  . . WA . . . 4     FDIV [0]        DECIMAL(31,24)  . . WA . . . 4 Campos. ------------------------------------------ #  Campo  Tipo  nTy  Nulable  Descripcion  1 FSUM DECIMAL(11,4) B10 3      2 FCOAL DECIMAL(10,4) B10 3      3 FPROD DECIMAL(20,9) B10 3      4 FDIV DECIMAL(31,24) B10 3      ------------------------------------------ The work-around is posible , if you are working from start and you are warned about the problem. But if you are porting a data model you must to reconstuct all views. A better solution to return (-1 or 65535) as the length or decs of a numeric field could be to do dataType scalation to a DOUBLE data type. This is not a good solution but better than now. The optimal solution es make presicion calculation for every column or almost the trivial cases like columns formed by  "coalesce", "case then", etc. The overflow or "data truncation" exception , for views, it's a going back , but almost put the problem in programmer's hands. Regards, Dario. Kris Jurka wrote: On Sat, 3 Jul 2004, Dario V. Fassi wrote: In the sample adjunct, you can see that error arise at the time when the view's sql text is parsed and saved in database catalog. Then generic NUMERIC type is forced for every calculated column without regard or precision. And at execute time the f2 column has varying type decimals (in row 2 you can see 4 decimals and in other rows has 3 decimals), this is not a behavior , this is an ERROR. It isn't clear that an operation like + should retain the same size restrictions as it's arguments. Consider adding two numeric(6,2) values of 9999.99, how do you handle the overflow? Your other arguments about the sizing of derived columns may make sense for your application, but it is unlikely that they make sense for all users. Note that you can put a cast into your view definition like so: CREATER VIEW v AS SELECT (a+b)::numeric(6,2) FROM tab; Kris Jurka --     Dario V. Fassi SISTEMATICA ingenieria de software  srl Ituzaingo 1628  (2000)  Rosario, Santa Fe, Argentina. Tel / Fax:  +54 (341) 485.1432 / 485.1353