JDBC handling of a Timestamp-Column
От | Ralf Edmund Stranzenbach |
---|---|
Тема | JDBC handling of a Timestamp-Column |
Дата | |
Msg-id | 002401c0ab39$36a989e0$032aa8c0@gwenhwyfar обсуждение исходный текст |
Ответ на | Where is locking done? ("Lawrence M. Kagan" <larry@alliedinfosystems.com>) |
Список | pgsql-hackers |
Hi, i've tried to fetch a TIMESTAMP column from the database into a Java Timestamp instance using the ResultSet.getTimestamp(int index) method. Whenever i call this method i get some error message: User.findUser: Bad Timestamp Format at 19 in 2001-03-19 22:05:50.45+01 Bad Timestamp Format at 19 in 2001-03-19 22:05:50.45+01 at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:447) at de.reswi.portal.User_DO.bind(User_DO.java:85) If i try to bind this column to a java.sql.Date instance using ResultSet.getDate(int index) everything works fine but i loose the precision i need. BTW: it's possible to write Timestamp type objects into the column. The Method ResultSet.setTimestamp(int index, Timestamp stamp) works fine. Ciao, - ralf ----- Original Message ----- From: "Lawrence M. Kagan" <larry@alliedinfosystems.com> To: <pgsql-hackers@postgresql.org> Sent: Thursday, February 22, 2001 11:43 AM Subject: [HACKERS] Where is locking done? > Here's my dillema: > > We are currently building a site with multiple machines to run our website > and client sites as well. I would like to run the postgres binary on 2 > machines concurrently to assist in load balancing. $PGDATA will be kept on > a RAID 1+0. I need to know where postgres does it's row & table locking. > If it's done in memory, I've got some problems! If it's done at or near > the $PGDATA directory (which sounds like bad performance decision) that > would be piece of cake. Any advice or ideas on this issue would be > GREATLY appreciated. > > Thanks in advance!! > > Larry > > > -- > Lawrence M. Kagan > Allied Infosystems, Inc. > E-mail: larry@alliedinfosystems.com > Web: www.alliedinfo.com > Phone: (954) 647-4600 > Toll-free: (877) WEB-5888 >
В списке pgsql-hackers по дате отправления: