SQLException: Invalid precision value. Cannot be less than zero

The exception occures in populate() method:

CachedRowSetImpl rowSet = new CachedRowSetImpl();
r=as.executeQuery("select * from an_tnratio");
rowSet.populate(r);

Table definition is:

-- Table: an_tnratio

-- DROP TABLE an_tnratio;

CREATE TABLE an_tnratio
(
ssize text,
edulh text,
tnratio numeric
)
WITH OIDS;
ALTER TABLE an_tnratio OWNER TO elan;

Stack trace:

java.sql.SQLException: Invalid column display size. Cannot be less than zero
at
javax.sql.rowset.RowSetMetaDataImpl.setColumnDisplaySize(RowSetMetaDataImpl.java:267)
at
com.sun.rowset.CachedRowSetImpl.initMetaData(CachedRowSetImpl.java:679)
at
com.sun.rowset.CachedRowSetImpl.populate(CachedRowSetImpl.java:597)
at com.sw4i.elan.engine.Table$1.doo(Table.java:51)
...

Driver version: 8.0-310 (postgresql-8.0-310.jdbc3.jar)
Sun JDK version: 1.5.0_01-b08
Database PosgreSQL 8.0.0 on i686-pc-mingw32, compiled by GCC gcc.exe(GCC)
3.4.2 (mingw-special)

The problem is "return -1" statement in
org.postgresql.jdbc2.AbstractJdbc2ResultSetMetaData.getPrecision():

case Types.NUMERIC:
Field f = getField(column);
if (f != null)
{
// no specified precision or scale
if (f.getMod() == -1)
{
return -1;
}
return ((0xFFFF0000)&f.getMod()) >> 16;
}
else
{
return 0;
}

After I have pached getPrecision(), getScale() and getColumnDisplaySize() to
return 0 instead of negative value, my program works fine. I haven't find in
JDBC specification what those methods should return for
"unknown/unspecified", but other drivers (like JdbcOdbcDriver) returns 0.

Nebojsa Vasiljevic

On Wed, 9 Feb 2005, Nebojsa Vasiljevic wrote:

> [CachedRowSet doesn't like -1 precision values for numeric]

This has been discussed, partially offlist, with Sun in the context of
getColumnDisplaySize returning -1 for text and varchar with no length
attribute fields. I've been waiting for a suggestion from Sun on what
value to use, or if they will alter their code to remove this check.

Your suggestion of using 0 passes their check, but still isn't legal:

jurka=# create table nt (a numeric(0,0));
ERROR: NUMERIC precision 0 must be between 1 and 1000

The -1 value is intended to indicate we don't know or unlimited or
similar and I don't particularly like it, but I've yet to hear a better
suggestion.

Kris Jurka

> This has been discussed, partially offlist, with Sun in the context of
> getColumnDisplaySize returning -1 for text and varchar with no length
> attribute fields. I've been waiting for a suggestion from Sun on what
> value to use, or if they will alter their code to remove this check.

javax.sql.rowset.RowSetMetaDataImpl class is part of Sun JDK 1.5.
I don't like Sun forces nonegative values in
javax.sql.rowset.RowSetMetaDataImpl,
but we can't change it. Sun will not change the JDK to make PosgreSQL driver
work.

Don't wait for Sun's suggestion, just look how other drivers works.

>
> Your suggestion of using 0 passes their check, but still isn't legal:
>
> jurka=# create table nt (a numeric(0,0));
> ERROR: NUMERIC precision 0 must be between 1 and 1000

"create table nt (a numeric(0,0))" is as illegal as "create table nt (a
numeric(-1,-1))".
Precision 0 stands for "create table nt (a numeric)".

Nebojsa

That's right we *can't change the spec*.

But hold on guys, I can put a try catch block for this and prevent
the SQLException from being thrown in the implementation,
wherever it is being called in from *other classes*.
And hence we can go on.

But yes I can't change the spec class from doing that.
It's(return -1 for variable length data) is used by various JDBC drivers
that way.

Does that help ?

Also, Can you give me the stack trace of the exception ?
I just want to confirm the try catch block I put is at the right place
(i.e. exception will be caught in CachedRowSetImpl.java),
and works with you guys.

Further I am going to file a bug with our bug tracking system
and get some feedback internally, so that I keep things black and white.
You can view it over the web later as well.

thanks,
Amit Handa,
Sun Microsystems Inc.

PS: Kevin seems to have vanished ;)
I was trying to help him with this and some other problems but never
heard back,
though I am also slow at times to get back to him because of other
commitments.

Kris Jurka wrote:

>On Wed, 9 Feb 2005, Nebojsa Vasiljevic wrote:
>
>
>
>>[CachedRowSet doesn't like -1 precision values for numeric]
>>
>>
>
>This has been discussed, partially offlist, with Sun in the context of
>getColumnDisplaySize returning -1 for text and varchar with no length
>attribute fields. I've been waiting for a suggestion from Sun on what
>value to use, or if they will alter their code to remove this check.
>
>Your suggestion of using 0 passes their check, but still isn't legal:
>
>jurka=# create table nt (a numeric(0,0));
>ERROR: NUMERIC precision 0 must be between 1 and 1000
>
>The -1 value is intended to indicate we don't know or unlimited or
>similar and I don't particularly like it, but I've yet to hear a better
>suggestion.
>
>Kris Jurka
>
>
>

> That's right we *can't change the spec*.
>
> But hold on guys, I can put a try catch block for this and prevent
> the SQLException from being thrown in the implementation,
> wherever it is being called in from *other classes*.
> And hence we can go on.
>
> But yes I can't change the spec class from doing that.
> It's(return -1 for variable length data) is used by various JDBC drivers
> that way.
>
> Does that help ?

Method

javax.sql.rowset.RowSetMetaDataImpl.setColumnDisplaySize()

throws exception after it is called from:

com.sun.rowset.CachedRowSetImpl.initMetaData(CachedRowSetImpl.java:679)

If you catch exception in CachedRowSetImpl.java, you have to decide what
value
to put in columnDisplaySize property. Possible answer is:

If columnDisplaySize, precision or scale property of ResultSetMetaData is -1
then appropriate property of RowSetMetaDataImpl will be 0.

(and you don't need try/catcher to do that)

If various JDBC drivers use -1, this may be reasonable solution.

Nebojsa

On Thu, 10 Feb 2005, Amit Handa wrote:

> Also, Can you give me the stack trace of the exception ?
> I just want to confirm the try catch block I put is at the right place
> (i.e. exception will be caught in CachedRowSetImpl.java),
> and works with you guys.

See the original message here:

http://archives.postgresql.org/pgsql-jdbc/2005-02/msg00049.php

> Further I am going to file a bug with our bug tracking system
> and get some feedback internally, so that I keep things black and white.
> You can view it over the web later as well.

Great.

> I was trying to help him with this and some other problems but never
> heard back, though I am also slow at times to get back to him because of
> other commitments.
>

Well please raise any other problems you have here on this list and we'll
try and help you out.

Kris Jurka