Hi,
Well may be you won't have less ugly code, but at least it will be hidden ;-)
I think the easiest way it to use you own PreparedStatement class. So you can
do any special treatment or workaround in a centralized and unique place.
JYL
- Original Message -
From: Peter Ondruska
>
> Well may be you won't have less ugly code, but at
least it will be hidden ;-)
>
> I think the easiest way it to use you own
PreparedStatement class. So you can do
> any special treatment or workaround in a centralized and unique place.
>
Hi JYL this is a very insightful and interesting
>
> Well may be you won't have less ugly code, but at
least it will be hidden ;-)
>
> I think the easiest way it to use you own
PreparedStatement class. So you can do
> any special treatment or workaround in a centralized and unique place.
>
Hi JYL this is a very insightful and interestin
You would only subclass PreparedStatement as public
MyPreparedStatement extends PreparedStatement and override setString
method. And in your code use replace PrepareStatement with
MyPreparedStatement.
On Thu, Jul 21, 2011 at 5:31 PM, Tomcat Programmer
wrote:
>
>>
>> Well may be you won't have les
Well I don't think you can redefine the classes used by the database driver.
What I use is wrapper classes for PreparedStatement instances.
BTW it has been very useful when Derby change the way they manage setBoolean
when column data type is a string type.
Before 10.8.2 setBoolean was setting '0'
