commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: Problem with Result Set returning null instead of Empty String
Date Wed, 25 Jan 2006 19:06:19 GMT

This is an Oracle specific problem. We use Oracle at work and it does 
not differentiate between empty string and null. The version of the 
driver you are using is very old and I think that it doesn't support 
JDBC 2.0. So it does not have a connection pool.

Dennis Lundberg

Chetan wrote:
> Stefan,
> But does this mean that DBCP has its own imlpementation of ResultSet etc ?
> Because i have been using the Oracle Drive contained in classes111.jar. Does
> this mean that DHCP changes the behaviour of ResultSet internally to return
> null when nulls appear in table columns ?
> Would it help if i used an older version of DBCP (say 1.0 or something)
> which i guess would be compliant to an older JDBC version ?
> Regards,
> Chetan
> ----- Original Message -----
> From: "Stefan Rufer" <>
> To: "Jakarta Commons Users List" <>
> Sent: Wednesday, January 25, 2006 5:20 PM
> Subject: Re: Problem with Result Set returning null instead of Empty String
>> On Wed, 25 Jan 2006, Chetan wrote:
>>> Earlier in my code, whenever i was doing a resultSet.getString('some
> column
>>> name'), the return value would be an empty string ('') in case the
> column in
>>> the database was null. However, after using DBCP, similar statements
> return
>> The JDBC specification (e.g. JDBC 3.0, Chapter states that for
>> database rows that contain NULL: "Column values that map to Java Object
>> types are returned as a Java null;"
>> Your implementation does not follow the JDBC specification, therefore it's
>> not possible to change the implementation easily.
>>> Is there any way by which i could make the DBCP connection broker return
> an
>>> empty string instead of a null so that i dont need to make changes in
>>> numerous places in my application to handle the null pointer case ?
>> I strongly recommend you to follow the JDBC specification (better change
>> your implementation now than later). This will make it possible to
>> exchange the implementation as you like.
>> cu
>> Stefan Rufer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message