Hi,
There are already PreparedStatement code in BasePeer that I've added about 3
months ago.
All you need to do is to replace all the BasePeer.doSelect() code in your
Base*Peer classes with BasePeer.doPSSelect(). This will do a
PreparedStatement.
~ Leon
----- Original Message -----
From: "Fedor Karpelevitch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 5:25 PM
Subject: RE: Handling of date/time in Peers
> this looks like the way to go, although using PSs seems like a better
> solution (also takes care of the strings and the rest), but using PSs
> requires more changes.
>
> All this should take is changing DB.getDateString to return {ts
'yyyy-MM-dd
> hh:mm:ss.f'} instead of just quoting. There is a problem, because this
> method method takes a string and we have to ensure the string is of
correct
> format....
>
>
> fedor.
>
> > -----Original Message-----
> > From: Diethelm Guallar, Gonzalo [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 14, 2001 5:35 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Handling of date/time in Peers
> >
> >
> > > > The problem is the SQL code the doSelect() generates; how
> > > > does it format the passed in date? It could generate this:
> > > >
> > > > SELECT * FROM A WHERE D = '12-25-1999'
> > > >
> > > > but if the DB is configured to expect dates as DD-MM-YYYY,
> > > > the query will fail.
> > >
> > > Another solution would be to have the DB adapters provide methods
> > > formatting Java's Date object as expected for each RDBMS.
> >
> > But that would not always work, because it also depends on the
> > client setup. For instance, with Oracle, the server may set a
> > date format like 'DD-MM-YYYY', and each client might modify
> > that date format to something else (including things such as
> > month names: JAN, FEB, etc., in any language supported by the
> > DB). You could probably argue that each instance of Turbine
> > could configure the date format separately, since each servlet
> > engine is really one "client" from the DB point of view, but I
> > still think using the documented JDBC escape syntax would be
> > a more generic solution:
> >
> > SELECT * FROM A WHERE D = {d '1999-12-25'}
> >
> > > Daniel
> >
> >
> > --
> > Gonzalo A. Diethelm
> > [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
