Thread: 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 ? 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
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 > > >
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
I'm still here. At this point, I have found a total of three problems using the CachedRowSet with Postgres. The first was the issue with the "Invalid column display size" exception. The other two seemed less related to the JDBC driver, but I will post more detailed descriptions to everyone outside of the mailing list. Kevin MacClay -----Original Message----- From: Kris Jurka [mailto:books@ejurka.com] Sent: Thursday, February 10, 2005 10:25 AM To: Amit Handa Cc: Nebojsa Vasiljevic; pgsql-jdbc@postgresql.org; Kevin MacClay; Brian Maguire Subject: Re: [JDBC] SQLException: Invalid precision value. Cannot be less than zero 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