Re: [JDBC] Still having trouble getting JDBC working
Corey,
This looks like it should work.
The only thing I can think of is that you need to export the classpath so
that it is visible outside of the .cshrc file?
what to you get when you execute
echo $CLASSPATH
The only other possibility is that you are using a real old version of the
driver. At one time the driver was in a package postgresql.Driver
try looking at the contents of the postgres char
jar -tvf postgresql.jar should list the contents.
Other than that your code looks like it should execute
Regards,
Dave
- Original Message -
From: "Corey Mosher" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, April 19, 2001 2:56 PM
Subject: [JDBC] Still having trouble getting JDBC working
Hi
Can anyone help me with this problem? I have jdk1.2.2 installed on
a freeBSD system. My class path in .cshrc is as follows:
set CLASSPATH = (/usr/local/lib/postgresql.jar)
I get this error:
Exception caught.
java.lang.ClassNotFoundException: org.postgresql.Driver
Exception caught.
java.sql.SQLException: No suitable driver
Ok
When running the following code (I replaced all the connection stuff with
x's for privacy reasons):
import java.io.*;
import java.sql.*;
import java.util.*;
public class test{
public static void main(String args[]){
Connection conn; // holds database connection
Properties prop = new Properties();
prop.put("jdbc.drivers", "org.postgresql.Driver");
System.setProperties(prop);
try {
Class.forName("org.postgresql.Driver"); // load database
interface
} catch(Exception exc){
System.err.println("Exception caught.\n" + exc);
}
try {
conn =
DriverManager.getConnection("jdbc:postgresql://:5432/x",
"x", "xx");
} catch(Exception exc){
System.err.println("Exception caught.\n" + exc);
}
System.out.println("Ok");
//conn.close();
}
}
Does the postgresql.jar file need any special permissions? Right now I
have:
-rw-r--r-- 1 root wheel 153145 Apr 16 08:53
/usr/local/lib/postgresql.jar
Any ideas?
Thanks.
Corey Mosher
-
Hub.Org Networking Services
251 Main St.
Wolfville, NS
Canada
B0P 1X0
Email: [EMAIL PROTECTED]
Phone: (902) 542-3657
-
PostgreSQL, Inc.
251 Main St.
Wolfville, NS
Canada
B0P 1X0
Email: [EMAIL PROTECTED]
Phone: (902) 542-0713
-
Fax: (902) 542-5386
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] multiple resource sets
Rolf,
Try this
ResultSet orderlines = _st.executeQuery();
while(orderlines.next()){
println(orderlines.get(1));
}
orderlines.close();
_st.close();
Dave
- Original Message -
From: Rolf Schillinger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 02, 2001 10:12 AM
Subject: [JDBC] multiple resource sets
Hi,
I`m having huge troubles using postgresql JDBC.
I do the following:
while (orderlines.next())
{
PreparedStatement as_st=db.prepareStatement(SELECT nr,beschreibung,
beschreibung_2,preis FROM artikel where nr=?);
System.out.println(orderlines.getRow()+ : +orderlines.getString(2));
}
As result I get:
1 : KKSC025
2 : KKTO045
which is totally okay cause the underlying table data is as follows:
id | nr| anzahl | eht
+-++-
1226969416 | KKSC025 | 22 | BU1
1226969416 | KKTO045 | 22 | KT
So far so good.
I know want to process the results of that orderlines query by adding:
as_st.setString(1,orderlines.getString(2));
as=as_st.executeQuery();
as.close();
to the above while loop.
Output now looks like:
1 : KKSC025
2 : Nalo schmal 45/50 rauchbraun
1) is still correct while 2) has the value of as_st/as now.
I`m getting desperate on that.
any help would be greatly appreciated.
thanks, Rolf
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[JDBC] Another patch
Hopefully we can slip this in before 7.1.1
This patch fixes a bug which occurs when setObject(1,obj) is called and obj
is of type Object, and is null
Regards,
Dave
[root@ebox2 jdbc2]# diff PreparedStatement.java.orig PreparedStatement.java
517a518,521
if (null == x){
setNull(parameterIndex,Types.OTHER);
return;
}
568a573,576
if (null == x){
setNull(parameterIndex,Types.OTHER);
return;
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[JDBC] Latest Binaries
For anyone looking for latest jar files; I have built the jars from the latest code snapshot and they are available for download at http://jdbc.fastcrypt.com Dave ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Ant ???
If you want to avoid compiling the driver you can get the binaries for postgres at http://jdbc.fastcrypt.com Dave - Original Message - From: rjtalbo [EMAIL PROTECTED] To: Bruce Momjian [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, May 26, 2001 12:07 PM Subject: [JDBC] Ant ??? Help ! I am trying to move from DB2 to Postgresql but Under Db2 , Linux and OS/2 and Windows I use VisualAge Java 3.0 ... VAJ includes a jdk of its own... Now it seems I will also have to add JDK 118 also have ANT to compile Postgresql.. What is Ant ?? I cannot find refrence to it in my SUN Manual , other Jave books, the IBM Devleopers site or Posgres Doc.. Except to say I must have it.. And oh yeah the Compiler error message.. Maybe I am not looking hard enough.. What is it and where can I get it?? And can I still use VAJ 3.0 after compile and install. Thanks very much Bob T. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Contributing fixes to Serilize.java
Changes have been made to the code just recently, and just submit your patches to the list Dave - Original Message - From: Ken K [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 19, 2001 4:13 PM Subject: [JDBC] Contributing fixes to Serilize.java Hi, I just used CVS to check out the JDBC code. A CVS log shows that no changes have been commited to the org/postgresql/util/Serialize.java since 10/09/2000. Does this sound about right or did I do something wrong with the check out? I have made some changes to this code (from an earlier check out) to get it to work correctly. If others are interested in my changes, how would I submit them? If anyone else is using Serialize and has made improvements to the code, I would be interested in seeing them. Ken ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[JDBC] setXXX patches
Bruce,
Here are the patches. I haven't tested them personally, but I did build a jar
for the guy who asked for it. He downloaded it, and said it worked. The jdbc1
patch is completely untested.
They are simple enough that they should work (The little guy on my left
shoulder is saying sure, sure ;)
Dave
Index: PreparedStatement.java
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java,v
retrieving revision 1.14
diff -c -r1.14 PreparedStatement.java
*** PreparedStatement.java 2001/07/04 15:08:32 1.14
--- PreparedStatement.java 2001/07/12 00:28:30
***
*** 267,273
{
// if the passed string is null, then set this column to null
if(x==null)
! set(parameterIndex,null);
else {
// use the shared buffer object. Should never clash but this makes
// us thread safe!
--- 267,273
{
// if the passed string is null, then set this column to null
if(x==null)
! setNull(parameterIndex,Types.OTHER);
else {
// use the shared buffer object. Should never clash but this makes
// us thread safe!
***
*** 323,336
*/
public void setDate(int parameterIndex, java.sql.Date x) throws SQLException
{
! SimpleDateFormat df = (SimpleDateFormat) tl_df.get();
! if(df==null) {
! df = new SimpleDateFormat(''-MM-dd'');
! tl_df.set(df);
! }
!
! set(parameterIndex, df.format(x));
// The above is how the date should be handled.
//
// However, in JDK's prior to 1.1.6 (confirmed with the
--- 323,339
*/
public void setDate(int parameterIndex, java.sql.Date x) throws SQLException
{
!if(null == x){
!setNull(parameterIndex,Types.OTHER);
!}else{
!SimpleDateFormat df = (SimpleDateFormat) tl_df.get();
!if(df==null) {
!df = new SimpleDateFormat(''-MM-dd'');
!tl_df.set(df);
!}
+ set(parameterIndex, df.format(x));
+}
// The above is how the date should be handled.
//
// However, in JDK's prior to 1.1.6 (confirmed with the
***
*** 353,359
*/
public void setTime(int parameterIndex, Time x) throws SQLException
{
!set(parameterIndex, ' + x.toString() + ');
}
/**
--- 356,366
*/
public void setTime(int parameterIndex, Time x) throws SQLException
{
!if (null == x){
!setNull(parameterIndex,Types.OTHER);
!}else{
!set(parameterIndex, ' + x.toString() + ');
!}
}
/**
***
*** 365,371
* @exception SQLException if a database access error occurs
*/
public void setTimestamp(int parameterIndex, Timestamp x) throws SQLException
! {
SimpleDateFormat df = (SimpleDateFormat) tl_tsdf.get();
if(df==null) {
df = new SimpleDateFormat(-MM-dd HH:mm:ss);
--- 372,381
* @exception SQLException if a database access error occurs
*/
public void setTimestamp(int parameterIndex, Timestamp x) throws SQLException
! {
!if (null == x){
!setNull(parameterIndex,Types.OTHER);
!}else{
SimpleDateFormat df = (SimpleDateFormat) tl_tsdf.get();
if(df==null) {
df = new SimpleDateFormat(-MM-dd HH:mm:ss);
***
*** 383,388
--- 393,399
// The above works, but so does the following. I'm leaving the above in, but this seems
// to be identical. Pays to read the docs ;-)
//set(parameterIndex,'+x.toString()+');
+}
}
/**
Index: PreparedStatement.java
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java,v
retrieving revision 1.7
diff -c -r1.7 PreparedStatement.java
*** PreparedStatement.java 2001/06/11 22:11:59 1.7
--- PreparedStatement.java 2001/07/12 00:33:51
***
*** 260,266
{
// if the passed string is null, then set this column to null
if(x==null)
! set(parameterIndex,null);
else {
StringBuffer b = new StringBuffer();
int i;
--- 260,266
{
// if the passed string is null, then set this column to null
if(x==null)
! setNull(parameterIndex,Types.OTHER);
else {
StringBuffer b =
RE: [JDBC] unexpected error.
Title: Message
It's
likely not the jdbc driver, but the postgres setup. do you have the ip address
setup in pg_hba.conf?
Dave
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of jpSent: July 17, 2001 11:39 AMTo:
[EMAIL PROTECTED]Subject: [JDBC] unexpected
error.
Hi,
I'm using postgresql 7.1.2 and jdbc7.0-1.2.
when I do a getConnection i receive this message
(in french).
Quelque chose de peu commun s'est produit pour
faire échouer le gestionnaire. Veuillez enregistrer cette exception:
{0}
That means that something unusal occured, and I
should record this exception: {0}
All was working well with postgresql 7.0.x, the
error occured when i upgraded to 7.1.2
I tried with jdk 1.2 an 1.3 ans the problem is
always the same.
Does some one know if it's due to the pgsql
installation, the jdbc version or something else?
thanks
--
Jean-Philippe Vignolohttp://www.phonevalley.com
"A bus station is where buses stop. A train
station is where trains stop. On my desk there is a work station"
RE: [JDBC] [PATCH] setTimestamp(int, Timestamp) fails on null timestamp
Dejan, Yes you are correct, I will submit a patch shortly. Dave -Original Message- From: Dejan Vucinic [mailto:[EMAIL PROTECTED]] Sent: July 11, 2001 7:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] [PATCH] setTimestamp(int, Timestamp) fails on null timestamp Dave, This has already been done in cvs, please get the binaries from http://jdbc.fastcrypt.com I just downloaded jdbc7.1-1.3.jar and I'm still seeing the same problem: java.lang.NullPointerException at org.postgresql.jdbc2.PreparedStatement.setTimestamp(PreparedStatement.ja va:381) My decompiler shows essentially the same code as the one in the 7.1.2 bundle (I didn't set up CVS yet, Windows-bound, more trouble than it's worth, etc. :). Thanks, --dv _ Get your FREE download of MSN Explorer at http://explorer.msn.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [JDBC] Methode is not yet implemented.
Joerg, I think there is some confusion here. Many people are using the driver quite successfully. Me included. Can you send me the code that doesn't work? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jörg Sommer Sent: July 18, 2001 3:18 PM To: [EMAIL PROTECTED] Subject: Re: [JDBC] Methode is not yet implemented. Dave Cramer schrieb: Joerg, Have you received a satisfactory answer to this problem yet? Dave Hi Dave and the rest :) I do many tests in the moment an I think I made a mistake (i'm not sure). Perhaps, I misunderstand a error message. I tested the SELECT query once more and the simple one works. (And much faster as with the ODBC-JDBC-Bridge). But a SELECT query with a bit more complicated structure, e.g. with and WHERE or ORDER do NOT work (not yet implemented). I test this in the moment because I don't want to wast your time once more (sorry for that if so) if I make a mistake. If the normal driver do not work I will test the one from fastcrypt and another one I found on blackdown... If I can not resolve my problem I will contact you once more... Thank you very much for your interest Jörg Sommer ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [JDBC] Large Objects
Yes, you have to commit the transaction at the end Con.commit(), or con.rollback() I think. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Lane Sent: July 29, 2001 4:20 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] Large Objects Daniel Fisher [EMAIL PROTECTED] writes: I'm having some trouble inserting a large object into the database. I'm fairly certain that the problem is in my java code because I wrote some quick PHP code and it worked fine. The main problem is I'm not getting any errors, so I'm kinda stumped. The code appears to run fine, but nothing is being inserted into the database. The query trace shows that you are starting a transaction (with BEGIN) and never committing it (no COMMIT or END). So when you close the connection, the transaction is rolled back, and its effects go away. I suppose that having done conn.setAutoCommit(false), you need to add a command to explicitly commit the transaction, but I don't know JDBC well enough to know how you do that... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: [JDBC] What needs to be done?
Rene, Certainly the blob support needs to be done. That seems to be high on the list Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rene Pijlman Sent: August 1, 2001 3:52 PM To: [EMAIL PROTECTED] Subject: [JDBC] What needs to be done? Hello, I read in comp.lang.java.databases that help is needed with development of the JDBC driver. Can someone please provide some pointers to what needs to be done? What are the open issues? Is it JDBC 2.0 compliance? PostgreSQL 7.1 support? I've seen a lot of postings about BLOB problems, and JDBC-standard BLOB support is on the overall todo list (http://www.postgresql.org/docs/todo.html). Is that still open for development? Is there anyone who has already looked at JDBC-standard BLOB support? If so, what are the challenges and complications? I can't promise anything yet, but I'll certainly consider helping with PostgreSQL/JDBC development. I'm fluent in Java and have developed a database driver before (for Oracle in a proprietary product). I'm about to spend quite a lot of time on developing a web application in Java on top of PostgreSQL, so I certainly have an interest in good JDBC support. If you're not a developer but a user of the driver, what are your current complaints or wish list items? Regards, René Pijlman ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: [JDBC] Bug found in the driver
Denis,
Do you get this error with current binaries from
http://jdbc.fastcrypt.com
Regards,
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Denis Bucher
Sent: August 8, 2001 7:44 AM
To: Steve Wampler
Cc: PGSQL-JDBC
Subject: Re: [JDBC] Bug found in the driver
At 11:07 07.08.01 -0700, you wrote:
Hello !
I agree with you. But is there someone that could find the exact
place to correct it ? This would be nice... And it would spare some
time in the mailling-lists, just do a google.com search at unusual
and you'll see
;-))
I thought I'd take more of a look at this (because I don't want to do
the work I'm supposed to be doing!). It looks for all the world to me
that the code is correct and that somehow MessageFormat.format() isn't
working properly. This is, of course, unlikely, since I'm pretty sure
Sun has tested MessageFormat quite a bit!
Do you have a simple test case I can run that will show the problem?
There's not much I can do without being able to reproduce the problem.
It is very easy to reproduce the bug !
Just change you pg_hba.conf so that the host on which you are has got no
entry. And you'll see :
Instead of saying unusual error, please record the following exception
: No pg_hba.conf entry for host 192.168.200.4, user postgres database
test (or something like that) it will say only :
unusual error, please record the following exception : {0}
Denis
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
RE: [JDBC] Bug found in the driver
Denis,
Can you do me a favour, and post a small program which can reproduce
your results.
If you have already done so, let me know and I will go and find it.
Dave
-Original Message-
From: Denis Bucher [mailto:[EMAIL PROTECTED]]
Sent: August 8, 2001 9:56 AM
To: PGSQL-JDBC
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] Bug found in the driver
At 09:05 08.08.01 -0400, you wrote:
Denis,
Do you get this error with current binaries from
http://jdbc.fastcrypt.com
Yes, with the latest binaries I get approximately :
EXCEPTION Quelque chose de peu commun sest produit pour faire ??chouer
le gestionnaire. Veuillez enregistrer cette exception: {0}
You can find it into : org/postgres/errors_fr.properties
With my modified/kludge version I get :
... java.sql.SQLException: Password authentification failed for user
'test'
Denis
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Denis Bucher
Sent: August 8, 2001 7:44 AM
To: Steve Wampler
Cc: PGSQL-JDBC
Subject: Re: [JDBC] Bug found in the driver
At 11:07 07.08.01 -0700, you wrote:
Hello !
I agree with you. But is there someone that could find the exact
place to correct it ? This would be nice... And it would spare
some time in the mailling-lists, just do a google.com search at
unusual
and you'll see
;-))
I thought I'd take more of a look at this (because I don't want to do
the work I'm supposed to be doing!). It looks for all the world to
me that the code is correct and that somehow MessageFormat.format()
isn't working properly. This is, of course, unlikely, since I'm
pretty sure Sun has tested MessageFormat quite a bit!
Do you have a simple test case I can run that will show the problem?
There's not much I can do without being able to reproduce the
problem.
It is very easy to reproduce the bug !
Just change you pg_hba.conf so that the host on which you are has got
no entry. And you'll see :
Instead of saying unusual error, please record the following exception
: No pg_hba.conf entry for host 192.168.200.4, user postgres database
test (or something like that) it will say only :
unusual error, please record the following exception : {0}
Denis
---(end of
broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of
broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
RE: [JDBC] hangs while getting large objects...
Chris, Try using the latest jar files from http://jdbc.fastcrypt.com DAve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of chris markiewicz Sent: August 15, 2001 3:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JDBC] hangs while getting large objects... hello. i occasionally have problems getting large objects from postgres. i am confident that this problem is a problem with my code and not postgres because i cannot find similar complaints and no one responded to my question from earlier this month (appears later in this email). I have a screen that loads several LOs (small images, mostly). Occasionally the process hangs on the rs.getBytes() line. Does anyone know what could be causing this? Separately, I have written a simple program that queries the table with the LOs. No problems - unless I run it while my application is hanging (then the simple program hangs indefinitely as well). I am able to run queries from the command line while this is going on, so it seems like the byte stream is plugging things up, but everything else is fine. Does anyone have any ideas what the problem could be? Everything works perfectly 90% of the time, but 90% isn't that good. At this point, I'm not even sure what to try. Are there any Postgres configuration changes I could make? Would Postgres logging tell me anything. I greatly appreciate your help. note - i'm running 7.0.3 on linux...connecting through jdbc. chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz Sent: Thursday, August 02, 2001 6:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [JDBC] errors while getting large objects... hello. my application uses large objects frequently...to render the main page, it might load anywhere from zero to 10 large objects - mostly images or documents. recently i started stress testing this page (making it always load many LOs) and i frequently encounter two different problems. 1. fastpath - autocommit is always false...i've verified this several times. my current workaround is to catch the fastpath error and resubmit the query...usually works on the second pass and rarely makes it to 4 passes (the current limit i have set). i have included a stack trace at the bottom of this message. does anyone have any ideas on this? i'm using 7.0.2 with the 7.0-1.2 jdbc driver. the occurences seem totally random...sometimes a page loads perfectly, sometimes i get three fastpath errors...sometimes the first load gets FP erros, sometimes the fifth page does. 2. hanging - i recently noticed that the processing sometimes (pretty frequently) hangs on the line of code that grabs the LO from the db...i've tried both: byte[] bytes = rs.getBytes(columnName); and InputStream is = rs.getBinaryStream(columnName); Same result for both. It hangs indefinitely. Similar to the fastpath - sometimes it happens, sometimes it doesn't...but it always happens within 5 screen loads of my stress test page. does anyone know if these problems were fixed in recent versions of postgresql? is anyone having similar problems? i greatly appreciate any help! thanks chris FastPath call returned ERROR: lo_tell: invalid large object descriptor (0) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141) at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:191) at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:203) at org.postgresql.largeobject.LargeObject.tell(LargeObject.java:232) at org.postgresql.largeobject.LargeObject.size(LargeObject.java:247) at org.postgresql.jdbc2.ResultSet.getBytes(ResultSet.java:370) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:514) at org.postgresql.jdbc2.ResultSet.getBinaryStream(ResultSet.java:616) at com.commnav.sbh.framework.persist.JDBCEngine.loadResultSet(JDBCEngine.ja va:4 40) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:284) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObje ct.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDoc umen t.java:586) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObje ct.j ava:208) at com.commnav.sbh.applications.documentmanager.FavoriteDocumentIteratorTag .doS tartTag(FavoriteDocumentIteratorTag.java:56) at apps.favorited_00025cuments._0002fapps_0002ffavoritedocuments_0002ffavor ited ocumentspidget_0002ejspfavoritedocumentspidget_jsp_24._jspService(_0002f apps _0002ffavoritedocuments_0002ffavoritedocumentspidget_0002ejspfavoritedoc umen tspidget_jsp_24.java:392) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at
RE: [JDBC] Current CVS will not compile
I can try to have a look at this later tonight. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian Sent: August 21, 2001 11:35 AM To: PostgreSQL jdbc list Subject: [JDBC] Current CVS will not compile Can someone look at current CVS and send me a patch so it compiles again? Not sure about the case but it may have to do with Array. --- compile: [javac] Compiling 3 source files to /usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/jdbc/build [javac] /usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/jdbc/org/postg resql/jdbc2/CallableStatement.java:311: The method org.postgresql.jdbc2.Array getArray(int) declared in class org.postgresql.jdbc2.CallableStatement cannot override the method of the same signature declared in interface java.sql.CallableStatement. They must have the same return type. [javac] public Array getArray(int i) throws SQLException [javac] ^ [javac] /usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/jdbc/org/postg resql/jdbc2/Connection.java:106: class org.postgresql.jdbc2.PreparedStatement is an abstract class. It can't be instantiated. [javac] PreparedStatement s = new PreparedStatement(this,sql); [javac] ^ [javac] /usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/jdbc/org/postg resql/jdbc2/PreparedStatement.java:32: class org.postgresql.jdbc2.PreparedStatement must be declared abstract. It does not define void setArray(int, java.sql.Array) from interface java.sql.PreparedStatement. [javac] public class PreparedStatement extends Statement implements java.sql.PreparedStatement [javac] ^ [javac] 3 errors -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
RE: [JDBC] Re: Couple of patches for jdbc driver
The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian Sent: August 22, 2001 2:18 PM To: Barry Lind Cc: [EMAIL PROTECTED]; Gunnar Ronning Subject: Re: [JDBC] Re: Couple of patches for jdbc driver I agree with Bruce. I think we are in good shape for 7.2. As long as there is an active developer community working on maintaining and upgrading the code base there shouldn't be problems. Once we get the jdbc.postgresql.org website updated then there can be an official place to post patches/updated drivers on a more frequent schedule than the server patch releases if necessary. Although realistically the same level of control/caution should be used in accepting patches into the current release as there is being used for the rest of the product (i.e. it needs to be a high priority bug and a low risk fix to risk destabilizing a production set of code). Even in 7.1 there were some jdbc fixes that made it into 7.1.2, and quite frankly I haven't seen anything since 7.1.2 that I would have considered a candidate for patching into 7.1.3 based on the criteria I feel should be applied. The 7.1.2 driver is IMHO high quality, and I use it in production environments. Part of the problem I see is a too frequent habit of telling users on this list who are having problems simply to get the latest code from the truck. We should instead be telling them to get the latest released code ie. 7.1.2 or 7.1.3. Agreed. Part of the problem is that while 7.1.2 jdbc works well for most uses, it has some gaping holes especially with system catalog information, and there are so many that we just tell people to get the CVS version. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] next() and PreparedStatement
Hi Mano, No the problem is not with jdbc. I do see a couple of things though 1) the semi-colon isn't necessary, but shouldn't break the code? try removing it. 2) returning the row that way looks a little dangerous. It is possible that the statement associated with the row would be gone after returning. dave On Tue, 2001-08-28 at 07:13, Mano lito wrote: Hi! We are developing a project using PostgreSQL 7.1.2 and JDBC drivers to exchange information with the database. Here is a piece of code to explain our problem: --- PreparedStatement pstmt; Connection connection; ResultSet rs = null; String query = new String( SELECT count(*) FROM foo_table WHERE foo_code=?; ); pstmt = connection.prepareStatement( query ); pstmt.setString( 1, foo ); rs = pstmt.executeQuery( query ); pstmt.close(); return rs.next(); -- the next() method will cause a java.lang.NullPointerException when the ResultSet comes from a PreparedStatement!!! Is this problem originated by the JDBC driver? We downloaded it from jdbc.fastcrypt.com but this error occurs again and again and in jdbc.postgresql.org we see 7.0.x drivers available but none 7.1 nor 7.1.2 exists... We'd appreciate any help you could give us.If your address is not the correct place to ask this questions please tell us. Thanks in advance. _ Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[JDBC] Read transactions don't work on 7.0.x db's
The following code fails on a 7.0 db, but works on a 7.1 db
It works fine with the 7.0 jar, but not with the latest code
I had a quick look and everything looks ok. I am going to keep looking
but I thought I would throw this out and see if anyone knows what is
going on
Dave
package test;
import java.sql.*;
/**
* Title:
* Description:
* Copyright:Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class TransactionSelect {
public TransactionSelect()
{
}
public static Connection getConnection( String url, String user,
String password)
{
try {
Class.forName(org.postgresql.Driver);
return java.sql.DriverManager.getConnection(url,user,password);
} catch(ClassNotFoundException ex) {
ex.printStackTrace(System.out);
} catch(SQLException ex) {
ex.printStackTrace(System.out);
}
return null;
}
public static void main(String[] args)
{
try{
Connection con =
getConnection(jdbc:postgresql://192.168.1.1/davec,davec,);
if (con == null){
throw new RuntimeException(no Connection);
}
con.setAutoCommit(false);
PreparedStatement pstmt = con.prepareStatement(select * from
categories );
ResultSet rs = pstmt.executeQuery();
con.commit();
con.close();
}catch (SQLException ex){
ex.printStackTrace(System.out);
}
}
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Read transactions don't work on 7.0.x db's Disregard my other patch
The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave Connection.patch ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Read transactions don't work on 7.0.x db's
From my POV there are two costs here: 1) The speed degradation by supporting multiple versions of postgres. I tend not to be too concerned by speed, and more concerned with ease of use. If speed really becomes an issue I can go into the code and remove the offending inefficiency caused by supporting multiple versions. 2) The barrier to entry by new jdbc, and postgres users trying to use postgres, and jdbc for the first time. If it doesn't work out of the box, then they will leave. I have a bias towards making it easier for people to use the software. However given the speed of server development. How far back are we going to support ? An argument can be made that since the software is free then there really is no reason not to upgrade. The biggest reason for me not to upgrade my server is reliability. What I have now works! I am hesitant to upgrade the server on a server which needs to run 24/7. That being said I am more likely to upgrade the jdbc driver, since: 1) it is really easy to back out the upgrade. 2) I have some ability to debug the jdbc driver and figure out what is going wrong. My ability to debug the postgres server is significantly less (approaching 0). So along with making it easier for new people to get the code up and running with a minimum of effort. I would like to take advantage of new jdbc features on older servers. My 2 cents worth Dave On Mon, 2001-09-03 at 19:46, Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Troubles using German Umlauts with JDBC
Alexander, You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database Dave On Tue, 2001-09-04 at 09:16, Alexander Troppmann wrote: Hi, we have troubles with German umlauts (e.g.: äüÖ) using the Postgresql JDBC driver form the 7.1.2 distribution... already tried to debug our Java software but it seems that the database driver modifies the umlauts in any way - a debug before any INSERT or after a SELECT query shows that the umlaut ü for example gets lost on the way though the JDBC driver... So e.g. the attribute city='München' gets M\?nchen when testing the JDBC driver using a simple Java program. Any idea what happens? Best regards, Alex T. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
Here is a revised patch with Barry's suggestions implemented
Dave
Index: Connection.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Connection.java,v
retrieving revision 1.26
diff -c -r1.26 Connection.java
*** Connection.java 2001/08/24 16:50:12 1.26
--- Connection.java 2001/09/04 17:21:29
***
*** 906,912
if (autoCommit)
ExecSQL(end);
else {
! ExecSQL(begin; + getIsolationLevelSQL());
}
this.autoCommit = autoCommit;
}
--- 906,917
if (autoCommit)
ExecSQL(end);
else {
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
this.autoCommit = autoCommit;
}
***
*** 935,941
public void commit() throws SQLException {
if (autoCommit)
return;
! ExecSQL(commit; begin; + getIsolationLevelSQL());
}
/**
--- 940,952
public void commit() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(commit;begin;+getIsolationLevelSQL());
! }else{
! ExecSQL(commit);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 949,955
public void rollback() throws SQLException {
if (autoCommit)
return;
! ExecSQL(rollback; begin; + getIsolationLevelSQL());
}
/**
--- 960,972
public void rollback() throws SQLException {
if (autoCommit)
return;
! if (haveMinimumServerVersion(7.1)){
! ExecSQL(rollback; begin+getIsolationLevelSQL());
! }else{
! ExecSQL(rollback);
! ExecSQL(begin);
! ExecSQL(getIsolationLevelSQL());
! }
}
/**
***
*** 1035,1055
if (haveMinimumServerVersion(7.1)) {
return ;
}
! String q = SET TRANSACTION ISOLATION LEVEL;
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! q = q + READ COMMITTED;
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! q = q + SERIALIZABLE;
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return q;
}
/**
--- 1052,1072
if (haveMinimumServerVersion(7.1)) {
return ;
}
! StringBuffer sb = new StringBuffer(SET TRANSACTION ISOLATION LEVEL);
switch(isolationLevel) {
case java.sql.Connection.TRANSACTION_READ_COMMITTED:
! sb.append( READ COMMITTED);
break;
case java.sql.Connection.TRANSACTION_SERIALIZABLE:
! sb.append( SERIALIZABLE);
break;
default:
throw new PSQLException(postgresql.con.isolevel,new
Integer(isolationLevel));
}
! return sb.toString();
}
/**
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [JDBC] Why JDBC 1?
Yes, it is, but many of the libraries, and methods which are used in version 2 of the driver aren't available in jdk1 so it won't compile or run. Dave On Tue, 2001-09-04 at 12:50, Rene Pijlman wrote: Perhaps this is a silly question, but why do we have separate JDBC 1 and 2 drivers? Isn't the JDBC 2 driver also an implementation of JDBC 1? Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] driver source code indentation
Well, my vote would be for a 2 space indent. Dave On Tue, 2001-09-04 at 16:59, Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: I am OK with the style used for the C code. However I would like the following additional step done for the java code: replace all tabs with spaces. I disagree with this, because then we are *not* applying the same coding standards in the backend and in JDBC. If you want to propose that we dispense with tabs throughout the system, feel free to propose that --- but it was shot down last time and likely will be again. I personally concur that four-space tabs is a horrible standard, and would much rather see us using eight-space tab stops. But I haven't been able to obtain any significant consensus for that view. Some developers apparently use editors where a physical tab character needs to equal the logical indent amount... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java)
I am willing to lend a hand if required Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian Sent: September 6, 2001 4:08 PM To: Rene Pijlman Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java) On Thu, 06 Sep 2001 14:30:49 -0400, you wrote: Ultimately it's the committer's responsibility to have confidence that the patch he applies is good; if he doesn't feel competent to check it himself, he should call for more reviewers. If he does feel sure about it, there's no need for procedural overhead. Agreed. If the committer is in the team of certified reviewers and is willing to review patches, our procedures are basically the same. Any committing assistance would be greatly appreciated, especially for jdbc. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
Chris, I'm curious; why are you using a hashtable for available connections, and how do you use it? I have been using a connection pool that uses a linked list, in LIFO mode to store available connections. I can donate the pool code if need be, it has been running for over a year with no problems. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of chris markiewicz Sent: September 6, 2001 2:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... spoke too soon. i see the error again (with 7.1) ...i no longer get the transaction isolation level issue, but i still get the NOTICE: current trans... error. some improvement, i guess. whether it's active? that isn't ever really an issue with our approach, unless i'm misunderstanding your question...this is an oversimplification, but: we have a connection pool that has a hashtable of available connections...there is also a user-connection hashtable with users as keys and connections as values. if a user wants to hit the db, the system first checks the user-connection hashtable. if no conn is associated with the user, it grabs a connection from available connection hashtable and puts it in the user-connection hashtable. the user then uses that connection etc etc...when the transaction is closed (by our system code) the connection is committed, removed from the the user-connection hashtable, and returned to the available hashtable. we don't use any threading, so there would never be two threads trying to use the same connection. should i be checking for anything else? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 2:29 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I am in the process of rewriting my connection pooling object. I'll share the results when i am finished later today I suspect. How are you determining whether a transaction is active? getAutoCommit? -Original Message- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 11:40 AM To: Missner, T. R.; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... trm i have been able to successfully avoid the problem for the last 20 minutes or so...my connection pooling system calls commit() on connections before returning them to the available pool (even if they were already 'committed')...i added a conditional to check whether or not it was already committed - if it was, i don't run the commit. this seems to prevent the transaction isolation level exception that always preceded my other exceptions. might this apply to your pooling system as well? thanks chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 10:33 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... I really don't understand why this is happening either. my current guess is that there is something going on in the way we are reusing connections. To answer your question I don't think there is any relationship between the 2 connections just that after the first one is corrupted I use the second one until it gets corrupted, then create new ones and start again. I have to assume that we are doing something wrong in our use of these connections and am focusing my effort in that direction right now. Sure wish one of the experts would chime in on this. t.r. -Original Message- From: chris markiewicz [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 7:17 AM To: Missner, T. R.; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL... tr things have gotten a little worse...i recently upgraded to postgresql 7.1 and now i am seeing this behavior even WITHOUT large objects. it happens much less frequently without LOs, but it still happens. i never saw this behavior in 7.0. are you seeing the same behavior? i guess i don't understand the following: right, each connection is a different process. so if you use the second connection, why should it fail too? it should have no relationship to the first connection, since it is a different process. i was discussing this with a co-worker and he suggested that the first connection might be spilling into the second (when you grab the first two connections, they may inhabit contiguous memory spaces...the first one gets corrupted and corrupts the second...i admit that i am no unix expert so while i can picture such a thing, i have no idea whether or not it is possible.) anyway, you grab the third connection and
Re: [JDBC] jdbc newbie question
Presuming that the spelling mistakes in the command line below are just that, I would suggest Putting the driver jar file into the $JAVA_HOME/jre/lib/ext directory, or adding it to the classpath Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Russ McBride Sent: September 16, 2001 9:55 PM To: [EMAIL PROTECTED] Subject: [JDBC] jdbc newbie question Hi guys, I've got a postgreSQL database setup and installed with jdbc, but I'm having trouble getting WebObjects to make a connection to the database. I'm getting a no driver detected error message. I've tried to load up the driver using: java -Djdbc.drivers=org.postgeresql.Drver example.ImageViewer which doesn't seem to work. Any suggestions? I'm running Mac OS 10.04, PG 7.1.2. TIA Russ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] getObject()
Sorry, they were until this morning probably older than Aug 24, I rebuilt them from source last evening Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Antonio Fiol Bonnín Sent: September 24, 2001 11:43 AM To: Antonio Fiol Bonnín; [EMAIL PROTECTED] Subject: Re: [JDBC] getObject() Hi Rene, I am wondering if the driver I am using is outdated (the functionality I am looking for seems to be already implemented, since Aug 24). In fact, I see what you saw about the cache, and looking into it a bit deeper, the cache is effectively updated (at least, on CVS HEAD). Could anyone tell me the date of the driver jars present on http://jdbc.fastcrypt.com ? If it's older than Aug 24, maybe the solution consists simply on creating the new jar files. Thank you very much. Antonio BTW: Brian Weller told me that: The cvs server recently changed, use this instead: cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login password: postgresql cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co pgsql End of Brian Weller e-mail. Thank you very much, Brian. I (Antonio Fiol Bonnín) wrote some time ago: Rene Pijlman wrote: On Fri, 21 Sep 2001 17:26:20 +0200, you wrote: When looking at the traffic that is going in and out of my machine, I see many (a real lot of) times the same request. Something like: select typname from pg_type where oid = XXX where XXX is a number (23, 1184, or maybe others) As I use the getObject method to retrieve the different ocjects contained in the resultset (I can't tell whether it's going to be an number or a timestamp beforehand), I imagine that this select statement is the one that helps getObject choose the right type. But, as every row in the resultset will have the same column types, couldn't some caching accelerate everything a lot? Looking at the source, I see signs of a caching mechanism in org.postgresql.Connection.getSQLType(), but at first glance it seems that this method doesn't actually add the type it retrieves to its own cache. That could very well be the cause of the problem. That will help, probably. Do you intend to fix this yourself, or are you seeking help from this list? If so, it would be nice if you could post a small program that reproduces the problem. Its probably very simple, but that way we can be sure we're looking at the same problem. I was going to try it myself. However, I have not been able to get the current sources from CVS, as stated below. (I have just retried) I have tried to connect to CVS, but instructions on http://www.ca.postgresql.org/devel-corner/docs/postgres/cvs.html did not work for me. I got: cvs login: authorization failed: server postgresql.org rejected access to /home/projects/pgsql/cvsroot for user anoncvs The CVS system is being migrated and there are lots of posts about it on the pgsql-hackers list. I'm not sure what the latest status is. The latest information should be on http://developer.postgresql.org/, but because of the recent shutdown of Great Bridge the system is in flux. I used the information present on that site. If you can have a look at it, what I do is a select a::integer, b::timestamp, c::float from table; and then I populate vectors by stating myVectorA.add(rs.getObject(a)); and the same for b and c. table has quite a few rows (about 100 to 700, average 250). When the code executes, if I start a network packet capture (after many packets have already passed), I see the stated request about the types (and presumably its response) going up and down. I am using the precompiled driver for Java 1.2 found on http://jdbc.fastcrypt.com. Thank you very much if you may help, either by letting me access the current source or by providing repaired binaries ;-) Now seriously, I am willing to repair this, if possible. Thanks. Antonio ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] Updated jdbc.postgresql.org website now in place
Looks good! Great work, One thing that isn't urgent but should be addressed in the future is now that CLASSPATH is deprecated, we should add instructions for placing the jar into the jre/lib/ext directory. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Barry Lind Sent: October 1, 2001 2:46 PM To: [EMAIL PROTECTED] Subject: [JDBC] Updated jdbc.postgresql.org website now in place The subject pretty much says it all. I have updated the jdbc website to contain more current information. It certainly could contain more information, but my primary goal was to get it current. If you have any suggestions, changes or additions please send them to the mail list. thanks, --Barry ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] why would an update only work if done twice?
Caoilte,
One thing that would be useful here is the logs from the postgres
backend to see what postgres is actually seeing. Is it possible to get a
look at the logs. I run code like yours in my applications with no
problems
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of C O'Connor
Sent: September 28, 2001 9:41 AM
To: [EMAIL PROTECTED]
Subject: [JDBC] why would an update only work if done twice?
I know this is a mistake I have made, and I am pretty sure it is a
mistake that has been occuring ever since I caught an SQL exception
(tried to insert value with already existing primary key).
At a guess I'd say that the db didn't recover properly because I didn't
rollback when i caught that exception.
THE PROBLEM
When I do an insert/update on the db using my jdbc code it goes through
correcty and does NOT raise any errors. However an examination of the db
using psql reveals that the table hasn't been updated at all. This is
scary, as it seems I cannot guarantee that any data has ever been
committed (I DO CALL COMMIT).
Furthermore if while my tomcat instance is still running (I have the
struts pooled connection running on top of it) I try and modify that
table in the database from within psql it hangs. It will only complete
when tomcat is stopped (presumably meaning that tomcat is hanging
somewhere despite not throwing an exception or hanging itself).
The SCARY thing is that I can fix this problem, with this code :-
conn = dataSource.getConnection();
if (auform.getOldUserName().equals() | auform.getOldUserName()
== null) {
if (adminUser.getAdminAccountAccess()) {
System.out.println(inserting admin user);
auuBean.insertAdminUser(conn, saveAdminUser);
} else
errors = true;
} else {
System.out.println(updating admin user);
auuBean.updateAdminUser(conn, saveAdminUser,
auform.getOldUserName());
}
conn.commit();
conn.close();
// CODE INSERTED TWICE
conn = dataSource.getConnection();
if (auform.getOldUserName().equals() | auform.getOldUserName()
== null) {
if (adminUser.getAdminAccountAccess()) {
System.out.println(inserting admin user);
auuBean.insertAdminUser(conn, saveAdminUser);
} else
errors = true;
} else {
System.out.println(updating admin user);
auuBean.updateAdminUser(conn, saveAdminUser,
auform.getOldUserName());
}
conn.commit();
conn.close();
// END CONFUSION
conn = null;
} catch (SQLException e) {
while (e != null) {
System.out.println(First Error Message: + e.getMessage());
e = e.getNextException();
}
if (conn != null) {
try {
conn.rollback();
} catch (SQLException f) {
System.out.println(heavy shit rolling back db transaction);
}
}
errors = true;
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
System.out.println(heavy shit losing a db pool connection);
errors = true;
}
conn = null;
}
}
A separate utility bean actually does the update or insert and throws
the exception for the action servlet to catch here.
My fix is the extra update/insert. For some reason this will update the
database whereas NOTHING else will. I have tried vacuuming, reindexing
and they don't seem to change anything.
I am running the latest version sid version of postgresql 7.1.3-4, and
connecting with a struts 1.0 pooled connection through tomcat. The code
above has worked before, but stopped working after it caught an SQL
exception (and before I put the rollback code in).
Can anyone suggest,
a) what the problem could be?
b) how i could fix it?
c) how to make sure it never happens again?
Caoilte
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] driver fails to handle strings in query statements properly
This is coming back from the backend as type unknown. If the single quotes are removed it works ok? I suppose we could return it as a string when we are in doubt? Is this reasonable since there are many other types it should be returned as? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Lora Goldston Sent: October 1, 2001 2:33 PM To: [EMAIL PROTECTED] Subject: [JDBC] driver fails to handle strings in query statements properly I am using jdbc7.0-1.2.jar. I am getting a No class found for unkown when I use strings in my query statements such as 'Container' seen in the query below. These queries work fine when I use Oracle or MySQL. This looks like a bug to me. I can work around this by explicitly casting the string in the query statement like: 'Container'::varchar. *Inside LDMSQLPLUGIN About to query db select container_20_ft_qty AS QTY_OH, 'Container' AS NOMENCLATURE from ue_summary_mtmc where uic = 'WAQJAA' EEE I caught an exception on resultSet.getObject(i + 1) -- Container No class found for unknown. at org.postgresql.Connection.getObject(Connection.java:621) at org.postgresql.jdbc2.ResultSet.getObject(ResultSet.java:741) at org.cougaar.domain.mlm.plugin.ldm.LDMSQLPlugIn.executeSQL(LDMSQLPlugIn.j ava:432 ) Is there a fix for this? Thanks in advance, Lora Goldston ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] J2SE 1.4 and other patches
Peter, Yes, that makes a lot of sense. One problem might exist with the sql.Types Jdk 1.4 probably defines extra types which won't be defined in jdk 1.3. Dave -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: October 18, 2001 1:41 PM To: Joseph Shraibman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] J2SE 1.4 and other patches Joseph Shraibman writes: Right. And a maintainer needs to make a jdbc3 direcotry and modifiy the ant files to use it when it detects a jdk of 1.4+ Couldn't the JDBC 3 stuff be implemented in the JDBC 2 driver as extension? The only reason we have a jdbc1 vs jdbc2 split is so that we can use jdk 1.2 functionality for the implementation of the JDBC 2 driver. So unless there is something in jdk 1.3 or 1.4 that is required or really useful for JDBC 3 we could probably avoid opening up yet another directory that always gets out of sync. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] [PATCHES] Ant configuration
The one issue I have with a non ant based build system is that it makes it difficult to build the driver on a windows machine. Currently I can build the driver on windows without using cygwin What problems does ant present? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Eisentraut Sent: October 18, 2001 5:04 PM To: Barry Lind Cc: Marko Kreen; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] [PATCHES] Ant configuration Barry Lind writes: I don't like this patch. If anything I think we should remove the dependency on ANT, not remove the dependency on make. The use of Ant originally seemed attractive because it would solve the detection of the jdk version, the portable invocation of the compiler, and the dependency generation. However, I must currently consider this experiment a failure, because for each problem Ant solves it introduces a load of worse problems into the system. Thus, if we can agree to work out a configure/make-based system for the next release I would be very much for it. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Please help me Urgent
You need to edit the pg_hba.conf file and add your host 199.9.200.199 to the file Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of dario silva Sent: October 15, 2001 3:12 PM To: [EMAIL PROTECTED] Subject: [JDBC] Please help me Urgent Hello. I have a server with postgresql 7.0 in mandrake 7.2. I can make a conection in the local machine, but when try to connect from other machine in my network appear the following message Something unusual has occured to cause the driver to fail. Please report this exception: Exception: java.sql.SQLException: No pg_hba.conf entry for host 192.9.200.199, user ADMIN, database SIGED Stack Trace: __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] J2SE 1.4 and other patches
Peter, Yes, that makes a lot of sense. One problem might exist with the sql.Types Jdk 1.4 probably defines extra types which won't be defined in jdk 1.3. Dave -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: October 18, 2001 1:41 PM To: Joseph Shraibman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] J2SE 1.4 and other patches Joseph Shraibman writes: Right. And a maintainer needs to make a jdbc3 direcotry and modifiy the ant files to use it when it detects a jdk of 1.4+ Couldn't the JDBC 3 stuff be implemented in the JDBC 2 driver as extension? The only reason we have a jdbc1 vs jdbc2 split is so that we can use jdk 1.2 functionality for the implementation of the JDBC 2 driver. So unless there is something in jdk 1.3 or 1.4 that is required or really useful for JDBC 3 we could probably avoid opening up yet another directory that always gets out of sync. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] [PATCHES] Ant configuration
Dave Cramer writes: The one issue I have with a non ant based build system is that it makes it difficult to build the driver on a windows machine. That is a valid concern that we're going to have to think about before we move to another method. What problems does ant present? * Ant needs to be installed. Of course this is not that much of a problem because you can simply install it. However, in automated build environments this might not be so easy, so people are just going to opt to leave out the JDBC driver. I'm sure we can use the Makefile to install the ant jar. * Ant doesn't provide an exit status; you have to watch the build to see if it works. This is unacceptable. Hmmm... I will look into this * Ant is buggy. We've had numerous reports of people having trouble with it for no apparent reason. I can also confirm from my own experience that numerous things don't seem to work the way they should work. I find this a little hard to believe given the number of projects which use ant as a primary build tool. jarkarta.apache.org for instance * In numerous attempts I have failed to convince Ant to place the built files in a tree different from the source tree. This really makes it a pain to build for multiple architectures (in Java, architecture = different jdk). I think this can be overcome. I have had no problems with this. * Ant doesn't support gcj last I checked. This is a real tragedy because gcj is the only free(tm) Java compiler available that seems to have a real future. Ant doesn't support Kaffe very well, btw. There are a number of free compilers, sun's is free, ibm's is free * The Ant language is not nearly as powerful as the stuff you can do in Makefiles. No comment I am Make challenged, but Ant is pretty comprehensive... * Ant is, well, different. I have personally spent a lot of effort to make all parts of PostgreSQL build the same way. Every new language has to reinvent configuration and build management: Perl MakeMaker -- total junk, Python distutils -- no thanks, Tcl -- well, at least they had the right idea. Ant -- one more thing to go wrong. Currently, everything you want to switch and change about the build of PostgreSQL you communicate to the configure script. How do you change the Java compiler? Good question -- not even the Ant manual can answer that because it depends on your particular distribution. Change the $JAVA_HOME environment variable AFAIK The problem is that Ant is a completely new and different tool that we have to deal with, but it doesn't actually solve a problem that hasn't been solved already. Well, this is a little philosophical, but my current focus is java, and ant is the de-facto standard for building java programs, so I guess I'm biased towards it. One thing it does solve is the ability to resolve inter-dependancies automatically. I have had builds which can only be built by ant, or by building the entire source tree at once. This is one feature which is usefull. As for a solution. My opinion is that we should support both. There seems to be enough interested parties to support both build tools. For the folks that want a Makefile, they can support it. If someone wants to support the build.xml file, then we should encourage it. I suspect that one of them will become obsolete on it's own. Dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] Does PG's JDBC support prepared statements at all?
Remove the single quotes from '?' there is no need for them. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dr. Evil Sent: October 20, 2001 7:14 PM To: [EMAIL PROTECTED] Subject: [JDBC] Does PG's JDBC support prepared statements at all? There is a bunch of documentation for prepared statements in PG's JDBC, it seems that the only thing prepared statements do is throw exceptions. Here's some code I'm trying: String newvalue = This is a new value; int accountnumber = 54; String qstring = UPDATE foo SET message = '?' WHERE number = ?; PreparedStatement st = db.prepareStatement(qstring); st.setString(1, newvalue); st.setInt(2, accountnumber); st.execute(); st.clearParameters(); st.close(); and I always get a Parameter index out of range error, which seems impossible. Any idea what's going on? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Code Fixes
Paul, Please send a patch to this list Thanks, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul Sent: October 24, 2001 8:47 PM To: [EMAIL PROTECTED] Subject: [JDBC] Code Fixes Hi, I have been working with your driver along with Forte for Java and it's not so Transparent Persistence. In trying to use your driver along with PostgreSQl 7.1 I have found some problems and fixed them in the DatabaseMetaData class. I am not an expert on Postgres, JDBC drivers or open source but I have been around the coding block a few times. Anyway Transparent Persistence now works with your driver and these fixes. So if I can assume Sun has implemented there end correctly my fixes should be correct. Anyway if you are interested in this code I can send it. Or you can explain how I can put it into your code base or send a link with an explanation. Thanks, Paul Vickerman Technical Architect Higher Ground Software Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[JDBC] Logging in the driver
I am looking at trying to debug the driver for staroffice. Unless someone can tell me otherwise, this requires logging. Currently the driver has a rudimentary mechanism for logging DriverManager.println() This is ok, but it doesn't provide for various levels of debugging. One possibility is to use something like log4j, but given the recent distaste for adding binaries to the download I am reluctant to add a library. At this point I will probably add for my own purposes a simple logging system that can be controlled by level. A while ago someone posted a message which suggested that they had added instrumentation to the driver. If this person is still on the list, please contact me. Cheers, Dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[JDBC] Proposal to remove Serialize from the JDBC driver
Hi folks I would like to propose removing the Serialize code from the driver. My reasons for doing so include: 1) It adds unnecessary complexity to the driver 2) I don't think this is the correct place for this code 3) There are much better ways to achieve persistence available. http://www.ambysoft.com/persistenceLayer.html If anyone has any objections, or comments please let them be known Dave ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] StarOffice question
It has to go into the staroffice/lib directory if you are using staroffice6. I quickly tried it and it fails due to a nullpointer exception. It is on my todo list to figure out. If you get it working let me know Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of tony Sent: October 24, 2001 4:58 AM To: [EMAIL PROTECTED] Subject: [JDBC] StarOffice question where do I put the postgresql.jar to connect StarOffice to Postgres? I have it in the /usr/java/jdk1.3/lib directory on the client machine (the one running staroffice) Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] No Suitable Driver
You need to load the driver first and then get the connection, also the
url for the connection s/b
jdbc:postgresql://hostname/testuser=testpassword=test
Assuming your database name is test
So your code needs to execute
Class.forName(org.postgresql.Driver)
And then
Connection db =
DriverManager.getConnection(jdbc:postgresql://hostname/testtest,test
);
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Guy McArthur
Sent: October 24, 2001 7:13 PM
To: [EMAIL PROTECTED]
Subject: [JDBC] No Suitable Driver
Hi, I'm trying to get a small test program going. I have built
PostgreSQL 7.1.3 on RedHat 6.2 with --java, installed and created
databases, verified with psql. The postgresql.jar is on my classpath.
My pg_hba.conf has:
localall password
host all 127.0.0.1 255.255.255.255 password
Here is my code:
import java.sql.*;
public class PostgresTest {
public static void main(String[] args) {
try {
Connection db =
DriverManager.getConnection(jdbc.postgresql:testuser=testpassword=tes
t);
// I've also tried all the permutations of getConnection() and urls. //
db, user, and password names have been changed to protect the innocent
// I've also tried Class.forName(org.postgresql.Driver) and //
Class.forName(org.postgresql.Driver).newInstance() instead of the arg.
db.close();
} catch(Throwable t) {
t.printStackTrace(System.out);
}
}
}
--
Running it with:
java -Djdbc.drivers=org.postgresql.Driver PostgresTest
where the db has been started by user postgres with:
/usr/local/pgsql/bin/postmaster -i -D /data/pgsql /data/pgsql/pgsql.log
21
And the error is:
java.sql.SQLException: No suitable driver
at java.sql.DriverManager.getConnection(DriverManager.java:537)
at java.sql.DriverManager.getConnection(DriverManager.java:199)
at PostgresTest.main(PostgresTest.java:6)
What is wrong?
--
Guy McArthur * email{[EMAIL PROTECTED]} http{guymcarthur.com}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [JDBC] DatabaseMetaData.getTables()
It appears the getBytes was previously being used to return a byte array of any arbitrary column. Fixes for blobs seem to have broken this. The question is as Jason pointed out which do we fix. It doesn't seem unreasonable to be able to return a byte array for any arbitray column. On the other hand is this the intended use? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Davies Sent: October 27, 2001 8:26 PM To: [EMAIL PROTECTED] Subject: [JDBC] DatabaseMetaData.getTables() Hi, There seems to be a problem with DatabaseMetaData.getTables() when I do the following: ResultSet R=conn.getMetaData().getTables(null, null, %, null); It throws a NullPointerException: java.lang.NullPointerException at org.postgresql.jdbc2.DatabaseMetaData.getTables(DatabaseMetaData.java:17 32) at Test.main(Test.java:66) Looking at the source, ResultSet.getBytes() is called and it returns null, causing this exception to be thrown. However I can use ResultSet.getString() without a problem. I'm using 7.1.3 at the moment. Does ResultSet.getBytes() need to be fixed or should getTables() be modified? I'd be grateful for any insights. Or you can just tell me to use the latest cvs version of PostgreSQL :) What is the consensus on supporting older versions, will you phase out old code when 7.2 comes out? -- Jason Davies [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] DatabaseMetaData.getTables()
Well I think we can restore the orignal functionality of getBytes so that it returns a byte array for other objects As long as we preserve the functionality for bytea types, and LargeObjects Dave -Original Message- From: Jason Davies [mailto:[EMAIL PROTECTED]] Sent: October 28, 2001 8:34 AM To: Dave Cramer Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] DatabaseMetaData.getTables() On Sun, Oct 28, 2001 at 07:14:42AM -0500, Dave Cramer wrote: It appears the getBytes was previously being used to return a byte array of any arbitrary column. Fixes for blobs seem to have broken this. The question is as Jason pointed out which do we fix. It doesn't seem unreasonable to be able to return a byte array for any arbitray column. On the other hand is this the intended use? This is what the documentation says: public byte[] getBytes(int columnIndex) throws SQLException Retrieves the value of the designated column in the current row of this ResultSet object as a byte array in the Java programming language. The bytes represent the raw values returned by the driver. It seems to imply that it _should_ return a byte array for any arbitary column. But as usual, it's up to us to decide. I think it's reasonable, since we are working with byte arrays in the code anyway. -- Jason Davies [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] OS version for driver
Mihai, The jdk is sun's jdk, and it should work on any platform Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mihai Gheorghiu Sent: September 26, 2001 12:45 PM To: [EMAIL PROTECTED] Subject: [JDBC] OS version for driver The most recent driver on jdbc.fastcrypt.com is 9/24; it is compiled on RH7.0 The most recent rpm for PG is 8/17, compiled on RH7.1. Is there a location where I can find it compiled on RH7.1 (and Sun jdk1.3)? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] JDBC Connection Pooling
Jack, No, it does not include connection pooling, there are quite a few readily availble connection pools out there Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of jcooney Sent: September 26, 2001 10:55 AM To: [EMAIL PROTECTED] Subject: [JDBC] JDBC Connection Pooling Does the 7.1-1.3 driver availalble on fastcrypt support JDBC 2.0 driver based connection pooling? I'm more than willing to look up the answer to this myself if someone can point be towards some technical documentation. Thanks, jc Jack Cooney Senior Consultant MONTAGE.DMC eBusiness Services A Division of ATT Canada office: (905) 602-7700 (ext.549) mobile: (416) 451-5629 [EMAIL PROTECTED] 5580 Explorer Drive Suite #600 Mississauga, Ontario L4W 4Y1 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] [Fwd: Re: Serialize]
Barry, Well you know my vote! Just to re-iterate: 1) I don't think it belongs in the driver 2) I think there are better ways of doing it No I haven't had a chance to look at the xa code yet Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Barry Lind Sent: October 8, 2001 2:26 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JDBC] [Fwd: Re: Serialize] Dave, I share your concerns about this functionality. In fact last month I wrote the following in response to a patch to this functionality. I wouldn't mind this being pulled out of the main code line for now and moved to contrib until it becomes more robust. Robert, Thanks for the patch. While I didn't review it too closely, what I saw seemed fine. However, I have concerns about the feature as a whole, which really has nothing to do with your patch. I don't like the approach taken here for serialization. It seems to me that this is a half baked attempt to reimplement native java serialization. Why not just use java serialization to do what it was intended for? We could then store the results of the serialization in a bytea column, or a LargeObject, or even in a separate table as is done here. However, I am unsure of the desireabilty of creating these additional tables. The bigest reason I don't like the additional tables is that the serialized objects don't ever get deleted. To the extent that this is documented, I think the feature should be marked as experimental with a caution that it may be changed in major non-backwardly compatible ways in the future. thanks, --Barry There are two areas in the current code that I am uncomfortable with. This serialize code and the code in org/postgresql/xa. Have you looked at the xa code? thanks, --Barry Dave Cramer wrote: While fixing the handling of unknown data type in the result set I was faced with wading through the Serialize code. I am wondering if this is really a required/desireable feature? How many people out there are actually using it? Do we need/want it? My thoughts are: 1) There are plenty of persistence layers which do this job much better. 2) I don't think this belongs in a driver. 3) The code will be simpler. Dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] driver fails to handle strings in query statements properly
I tried it on a table which id was an int Using select 'id' as xxx from ... Returns xxx as an unknown type Using select id as xxx from... returns xxx as an int I have no idea how the backend handles this, but if it can figure it out in one instance why can't it figure it out when I put single quotes around it? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Lane Sent: October 2, 2001 5:19 PM To: Barry Lind Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] driver fails to handle strings in query statements properly Barry Lind [EMAIL PROTECTED] writes: My thoughts as well. If we encounter an 'unknown' type, just return it as a String. Do you have time to fix this? I suppose we could return it as a string when we are in doubt? Is this reasonable since there are many other types it should be returned as? The backend will presently default to treating 'unknown' as type 'text' if it hasn't got any better idea what to do, so I think it's reasonable for JDBC to do likewise. I believe the only case in which you could see 'unknown' reported as a query result type is if a string literal is SELECTed without any processing being done on it, viz SELECT 'foo' As soon as the literal is passed to a function or operator, sorted, grouped, etc, the system will insist on resolving it to a non-unknown type. If the usage context doesn't provide any other hint, 'text' will be the chosen type. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] driver fails to handle strings in query statements properly
As I said, I have no idea how the backend handles it when it is quoted. You mention that it's not a column reference, but it does get data from the id column? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Lane Sent: October 2, 2001 6:16 PM To: [EMAIL PROTECTED] Cc: 'Barry Lind'; [EMAIL PROTECTED] Subject: Re: [JDBC] driver fails to handle strings in query statements properly Dave Cramer [EMAIL PROTECTED] writes: I tried it on a table which id was an int Using select 'id' as xxx from ... Returns xxx as an unknown type Using select id as xxx from... returns xxx as an int I have no idea how the backend handles this, but if it can figure it out in one instance why can't it figure it out when I put single quotes around it? Uh ... when you put single quotes around it, it's a literal, not a column reference ... and whatever one might think about 'id', it's certainly not an integer. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] driver fails to handle strings in query statements properly (ignore my last post)
Ok, I need some sleep, now I see what it does, which is probably not what the user wanted, but I have fixed the driver to it doesn't throw an exception. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer Sent: October 2, 2001 9:12 PM To: 'Tom Lane' Cc: [EMAIL PROTECTED] Subject: Re: [JDBC] driver fails to handle strings in query statements properly As I said, I have no idea how the backend handles it when it is quoted. You mention that it's not a column reference, but it does get data from the id column? Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Lane Sent: October 2, 2001 6:16 PM To: [EMAIL PROTECTED] Cc: 'Barry Lind'; [EMAIL PROTECTED] Subject: Re: [JDBC] driver fails to handle strings in query statements properly Dave Cramer [EMAIL PROTECTED] writes: I tried it on a table which id was an int Using select 'id' as xxx from ... Returns xxx as an unknown type Using select id as xxx from... returns xxx as an int I have no idea how the backend handles this, but if it can figure it out in one instance why can't it figure it out when I put single quotes around it? Uh ... when you put single quotes around it, it's a literal, not a column reference ... and whatever one might think about 'id', it's certainly not an integer. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] Question of JDBC Driver
The updateable result set functionality has not been implemented. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Adile Abbadi Sent: October 12, 2001 9:57 PM To: [EMAIL PROTECTED] Subject: [JDBC] Question of JDBC Driver Hi there, I'm using PostgreSQL ver 7.1 and I am having a bit of a problem with the jdbc driver. I want to use some of the ResultSet methods, but I seem to be having difficulity using some of them. I can't seem to do anything against an updatable ResultSet, such as moveToInsertRow or updateString. Here is a snipnet of my code Statement SQLStatement = Conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_ UPDATABLE); String query = select * from cust_acct;; ResultSet sr = SQLStatement.executeQuery(query); sr.moveToInsertRow(); sr.updateString(compname,props[4]); sr.insertRow(); sr.close(); SQLStatement.close(); And this is the error I get javax.servlet.ServletException: This method is not yet implemented. at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContex tImpl.java:459) at cquay.admin.cms._0002fcquay_0002fadmin_0002fcms_0002fcreate_0005fcust_00 02ejspcreate_0005fcust_jsp_76._jspService(_0002fcquay_0002fadmin_0002fcm s_0002fcreate_0005fcust_0002ejspcreate_0005fcust_jsp_76.java:576) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle t.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav a:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnec tion(Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416 ) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49 8) at java.lang.Thread.run(Thread.java:484) Root cause: This method is not yet implemented. at org.postgresql.Driver.notImplemented(Driver.java:382) at org.postgresql.jdbc2.UpdateableResultSet.moveToInsertRow(UpdateableResul tSet.java:98) at cquay.admin.cms._0002fcquay_0002fadmin_0002fcms_0002fcreate_0005fcust_00 02ejspcreate_0005fcust_jsp_76._jspService(_0002fcquay_0002fadmin_0002fcm s_0002fcreate_0005fcust_0002ejspcreate_0005fcust_jsp_76.java:174) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle t.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav a:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnec tion(Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416 ) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49 8) at java.lang.Thread.run(Thread.java:484) I have imported java.sql.* and I can do executeUpdate or retreave data via the ResultSet Object. Any assistance you can provide would be appreciated. Cheers Adile Mr. Adile Abbadi - Business Analyst - Cquay Inc Ph: (403) 261-6568 - Fax: (403) 233-2135 - Cell: (403) 630-8901 Email: [EMAIL PROTECTED] - Website: www.cquay.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 2: you can get off all lists at once with
Re: [JDBC] J2SE 1.4 and other patches
What do you see wrong with the build process? Ant is used to build the driver! Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joseph Shraibman Sent: October 16, 2001 5:45 PM To: Rene Pijlman Cc: Mark Lillywhite (pg-jdbc); [EMAIL PROTECTED] Subject: Re: [JDBC] J2SE 1.4 and other patches I think what most needs to be done is for someone to update the build process, so people who want to hack code will have somewhere to start from. Rene Pijlman wrote: On 13 Oct 2001 11:16:07 +1000, you wrote: I was just wondering if anyone is working on support for JDK1.4 for the postgresql drivers. Not AFAIK. It appears that there are some new methods defined in a few interfaces that need to be implemented (presumably to just throw the unimplemented exception?). Do you mean JDBC 3.0 methods? What methods precisely? Are they implementable? Also, I have a patch for DatabaseMetaData to fix a bug in the metadata returned for BigDecimals. I have already tried to submit this patch 2 or 3 times (to peter@retep) but never heard back. It's only about 4 LOC but it makes introspecting the database much better. Is this the place to post a patch, and if I do, am I likely to get a response? You can send patches to the [EMAIL PROTECTED] list, preferably with a CC to this list. Yes, you will get a response. Usually, a patch is applied within a week (if the patch is good, of course). If a patch to the JDBC driver needs discussion first, that should be on this list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] J2SE 1.4 and other patches
Ok, what specifically in jdbc 3.0 do people want implemented? All of the callable statement stuff is not applicable to postgres Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Barry Lind Sent: October 17, 2001 12:53 AM To: Joseph Shraibman Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] J2SE 1.4 and other patches Anyone can do that by submitting a patch. I don't see anything special that needs to be done. --Barry Joseph Shraibman wrote: Right. And a maintainer needs to make a jdbc3 direcotry and modifiy the ant files to use it when it detects a jdk of 1.4+ Dave Cramer wrote: What do you see wrong with the build process? Ant is used to build the driver! Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joseph Shraibman Sent: October 16, 2001 5:45 PM To: Rene Pijlman Cc: Mark Lillywhite (pg-jdbc); [EMAIL PROTECTED] Subject: Re: [JDBC] J2SE 1.4 and other patches I think what most needs to be done is for someone to update the build process, so people who want to hack code will have somewhere to start from. Rene Pijlman wrote: On 13 Oct 2001 11:16:07 +1000, you wrote: I was just wondering if anyone is working on support for JDK1.4 for the postgresql drivers. Not AFAIK. It appears that there are some new methods defined in a few interfaces that need to be implemented (presumably to just throw the unimplemented exception?). Do you mean JDBC 3.0 methods? What methods precisely? Are they implementable? Also, I have a patch for DatabaseMetaData to fix a bug in the metadata returned for BigDecimals. I have already tried to submit this patch 2 or 3 times (to peter@retep) but never heard back. It's only about 4 LOC but it makes introspecting the database much better. Is this the place to post a patch, and if I do, am I likely to get a response? You can send patches to the [EMAIL PROTECTED] list, preferably with a CC to this list. Yes, you will get a response. Usually, a patch is applied within a week (if the patch is good, of course). If a patch to the JDBC driver needs discussion first, that should be on this list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] [PATCHES] Ant configuration
Given that ant is (or is becoming) the defacto standard for building java apps I am reluctant to remove it. A number of projects simply include the ant jar in the download. Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Barry Lind Sent: October 17, 2001 4:23 PM To: Marko Kreen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] [PATCHES] Ant configuration I don't like this patch. If anything I think we should remove the dependency on ANT, not remove the dependency on make. By requiring ANT, we provide yet another hurdle for someone wanting to use JDBC with postgres. I would prefer that the build environment be the same for the database as for the jdbc code. Anything that makes it more difficult to download the source and get going with it is a negative in my opinion. And from my perspective requiring the download of an additional tool (ANT in this case) makes it more difficult. I already know that some binary distributions of postgres do not include JDBC simply because it is too complex to get ANT installed in their build environment. (complex perhaps isn't the right word, but it is more work than they are willing to put in for a small feature of postgres). thanks, --Barry Marko Kreen wrote: I dusted a old patch that integrates Ant better with autoconf. It creates a file src/ant.cfg.in to pass autoconf parameters to Ant. Now Ant can be used directly, without going through Makefile. 'install.directory' is still passed in Makefile to keep DESTDIR working. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
