Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"
From: Lew on 5 Jul 2010 10:44
Hole wrote:
> For everyone is interested in the TimeZone thing:
>
> If your original poor UTC string date passes unharmed any "silent&
> transparent" conversion from a TimeZone to your local default one and
> you have to insert that Timestamp in your database, remember to use
> the method CallableStatement.setTimestamp() that accepts a Calendar
> instance with the proper TimeZone adjusted, since the JDBC Driver will
> use your default TimeZone when it constructs the TIMESTAMP.

Even better, since 'CallableStatement' is intended for stored procedure use
'PreparedStatement', intended to execute SQL commands. I don't understand the
wisdom of 'CallableStatement' if you're not invoking stored procedures.

<http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setDate(int,
java.sql.Date, java.util.Calendar)>
allows you to use a 'TimeZone' other than the default.

As a minute or two with the Javadocs would reveal.

Retrieval can use the corresponding
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getDate(int,
java.util.Calendar)>

and of course there are parallel
<http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setTimestamp(int,
java.sql.Timestamp, java.util.Calendar)>

and
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getTimestamp(java.lang.String,
java.util.Calendar)>

Note further that 'CallableStatement' inherits these setter methods.

--
Lew
From: Hole on 5 Jul 2010 12:15
On 5 Lug, 16:44, Lew <no...(a)lewscanon.com> wrote:
> Hole wrote:
> > For everyone is interested in the TimeZone thing:
>
> > If your original poor UTC string date passes unharmed any "silent&
> > transparent" conversion from a TimeZone to your local default one and
> > you have to insert that Timestamp in your database, remember to use
> > the method CallableStatement.setTimestamp() that accepts a Calendar
> > instance with the proper TimeZone adjusted, since the JDBC Driver will
> > use your default TimeZone when it constructs the TIMESTAMP.
>
> Even better, since 'CallableStatement' is intended for stored procedure use
> 'PreparedStatement', intended to execute SQL commands.  I don't understand the
> wisdom of 'CallableStatement' if you're not invoking stored procedures.
>
> <http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html...,
> java.sql.Date, java.util.Calendar)>
> allows you to use a 'TimeZone' other than the default.
>
> As a minute or two with the Javadocs would reveal.
>
> Retrieval can use the corresponding
> <http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getDate...,
> java.util.Calendar)>
>
> and of course there are parallel
> <http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html...,
> java.sql.Timestamp, java.util.Calendar)>
>
> and
> <http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getTime...,
> java.util.Calendar)>
>
> Note further that 'CallableStatement' inherits these setter methods.
>
> --
> Lew

Hi Lew,

indeed, I call an SP from my class.
However, even if I didn't check, I was sure that same signature
methods are available in other JDBC classes with similar aims so the
reader of this thread could have easily checked himself.

I thank you for your valuable tips and suggestions but I don't
understand your polemical writing.
From: Lew on 5 Jul 2010 12:32
Hole wrote:
>>> For everyone is interested in the TimeZone thing:
>>
>>> If your original poor UTC string date passes unharmed any "silent&
>>> transparent" conversion from a TimeZone to your local default one and
>>> you have to insert that Timestamp in your database, remember to use
>>> the method CallableStatement.setTimestamp() that accepts a Calendar
>>> instance with the proper TimeZone adjusted, since the JDBC Driver will
>>> use your default TimeZone when it constructs the TIMESTAMP.

Lew wrote:
>> Even better, since 'CallableStatement' is intended for stored procedure use
>> 'PreparedStatement', intended to execute SQL commands. I don't understand the
>> wisdom of 'CallableStatement' if you're not invoking stored procedures.
>>
>> <http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html...,
>> java.sql.Date, java.util.Calendar)>
>> allows you to use a 'TimeZone' other than the default.
>>
>> As a minute or two with the Javadocs would reveal.
>>
>> Retrieval can use the corresponding
>> <http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getDate...,
>> java.util.Calendar)>
>>
>> and of course there are parallel
>> <http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html...,
>> java.sql.Timestamp, java.util.Calendar)>
>>
>> and
>> <http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#getTime...,
>> java.util.Calendar)>
>>
>> Note further that 'CallableStatement' inherits these setter methods.

Hole wrote:
>> --
>> Lew

Please don't quote sigs.

> Hi Lew,
>
> indeed, I call an SP from my class.

A detail you omitted. Now I comprehend.

Your advice was absolute - "remember to use the method
CallableStatement.setTimestamp()" - as if there were no alternatives.

> However, even if I didn't check, I was sure that same signature
> methods are available in other JDBC classes with similar aims so the
> reader of this thread could have easily checked himself.

And now they have help knowing where to look.

> I thank you for your valuable tips and suggestions but I don't
> understand your polemical writing.

Huh?

I don't want to engender dispute. My aim is to encourage liberal use of
Javadocs, and to point out alternatives the absolutism of your advice foreclosed.

I've been using JDBC since my first Java job over a decade ago, and I still
read and reread the Javadocs for 'Statement', 'PreparedStatement', 'ResultSet'
and the rest, never mind the newer APIs.

--
Lew
First  |  Prev  | 
Pages: 1 2 3 4
Prev: jsf big form
Next: Followup to "Serious concurrency problems on fast systems"