Unix Technical Forum

SQLException: Invalid precision value. Cannot be less than zero

This is a discussion on SQLException: Invalid precision value. Cannot be less than zero within the pgsql Interfaces jdbc forums, part of the PostgreSQL category; --> The exception occures in populate() method: CachedRowSetImpl rowSet = new CachedRowSetImpl(); r=as.executeQuery("select * from an_tnratio"); rowSet.populate(r); Table definition is: ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Interfaces jdbc

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-15-2008, 11:03 PM
Nebojsa Vasiljevic
 
Posts: n/a
Default 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.setColumnDispl aySize(RowSetMetaDataImpl.java:267)
at
com.sun.rowset.CachedRowSetImpl.initMetaData(Cache dRowSetImpl.java:679)
at
com.sun.rowset.CachedRowSetImpl.populate(CachedRow SetImpl.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.AbstractJdbc2ResultSetMetaDat a.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


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-15-2008, 11:03 PM
Kris Jurka
 
Posts: n/a
Default Re: SQLException: Invalid precision value. Cannot be less



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


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-15-2008, 11:03 PM
Nebojsa Vasiljevic
 
Posts: n/a
Default Re: SQLException: Invalid precision value. Cannot be less than zero



> 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.setColumnDispl aySize()

throws exception after it is called from:

com.sun.rowset.CachedRowSetImpl.initMetaData(Cache dRowSetImpl.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


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-15-2008, 11:03 PM
Nebojsa Vasiljevic
 
Posts: n/a
Default Re: SQLException: Invalid precision value. Cannot be less than zero


> 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


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 04-15-2008, 11:04 PM
Kris Jurka
 
Posts: n/a
Default Re: SQLException: Invalid precision value. Cannot be less



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...2/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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #6 (permalink)  
Old 04-15-2008, 11:04 PM
Amit Handa
 
Posts: n/a
Default Re: SQLException: Invalid precision value. Cannot be less than

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
>
>
>



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 08:44 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com