Re: [JDBC] Need help with JDBC driver. Problem, - getExportedKeys
Hi all. He's right. The DatabaseMetaData.getExportedKeys() method is simply not yet implemented, both in the jdb1 and the jdbc2 driver. Its open for development. If someone can write the query on the system catalogs I'll be glad to implement the Java code and a test case. The documentation of the info we need is available on http://java.sun.com/j2se/1.3/docs/api/java/sql/DatabaseMetaData.html (look for getExportedKeys). An initial version for get(Imported|Exported)Keys and getCrossReference is available in jxDBCon (http://jxbdcon.sf.net) the file can be extracted automatically from CVS under http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/jxdbcon/src/org/sourceforge/jxdbcon/postgresql/PGDatabaseMetaData.java?rev=1.21content-type=text/plain Feel free to use it for a quick start. Initial means: - not tested - don't like its algorithm - needs to be improved But nevertheless it works. Regargs, Keve ---(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] jdbc ResultSetMetaData::isWritable()
hello,
i think there's a simple error in the isWritable method of the
ResultSetMetaData class in the jdbc2 postgresql driver. the isWritable method
looks like this:
public boolean isWritable(int column) throws SQLException
{
if (isReadOnly(column))
return true;
else
return false;
}
and isReadOnly looks like this:
public boolean isReadOnly(int column) throws SQLException
{
return false;
}
hence, isWritable() will always return false. this is something of a problem
:) just switch the booleans in isReadOnly and everything should work just
fine. i have verified this in the 7.1.3 source, and it appears to work the
same way in at least 7.1.2 as well.
let me know if i can provide further information.
thanks,
ian wehrman
--
Labfire, Inc.
Seamless Technical Solutions
http://labfire.com/
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[JDBC] error - NOTICE: current transaction is aborted, queries ignored until end of transaction block
Hello. I have been having problems with postgresql large objects...i have been searching the archives of this group and i have posted a question or two but i have so far be unable to resolve the issues. right now, i have a screen that loads a few LOs...they occasionally don't make it to the screen. i see a couple of different errors in my log files (which i included below). i turned on debugging (d2) and i see the following on many of my queries (see below). DEBUG: StartTransactionCommand DEBUG: query: SELECT DISTINCT sbhd.timestamp AS modifydate, sbhd.versionid AS versionid, sbhd.documentdescription AS sbhdocumentdescription, sbhd.maxversions AS maxversions, sbhd.documentid AS sbhdocumentid, sbhd.hidden AS hidden, sbhd.documentpath AS sbhdocumentpath, sbhd.parentid AS parentid, sbhd.ownerid AS ownerid, sbhd.documentname AS sbhdocumentname, sbhd.createtimestamp AS createdate FROM document sbhd WHERE sbhd.documentpath = '/cmarkiew/porsche/porsche_speedster.jpg' DEBUG: ProcessQuery DEBUG: CommitTransactionCommand DEBUG: StartTransactionCommand DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel, creatorid, documentid, versionorder, datestamp, versioncontent FROM document_version WHERE versionid = 1034272 NOTICE: current transaction is aborted, queries ignored until end of transaction block DEBUG: CommitTransactionCommand DEBUG: StartTransactionCommand DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel, creatorid, documentid, versionorder, datestamp, versioncontent FROM document_version WHERE versionid = 1034272 NOTICE: current transaction is aborted, queries ignored until end of transaction block DEBUG: CommitTransactionCommand what causes the current transaction is aborted, queries ignored until end of transaction block? the first query in the above debug block does not load an LO, but the second one does. after the second query, seems like all subsequent have that message...my log file starts getting a bunch of the following: No results were returned by the query. at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:274) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:402) at com.commnav.sbh.framework.documentmanager.SBHDocument.getSBHDocument(SBHDocu ment.java:363) at com.commnav.sbh.servlets.DocumentManager.doPost(DocumentManager.java:201) at com.commnav.sbh.servlets.CommnavServlet.doGet(CommnavServlet.java:170) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) 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.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) No results were returned by the query. at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:63) at com.commnav.sbh.framework.persist.JDBCEngine.load(JDBCEngine.java:274) at com.commnav.sbh.framework.persist.PersistenceObject.load(PersistenceObject.j ava:169) at com.commnav.sbh.framework.documentmanager.SBHDocument.loadComplex(SBHDocumen t.java:402) at com.commnav.sbh.framework.documentmanager.SBHDocument.getSBHDocument(SBHDocu ment.java:363) at com.commnav.sbh.servlets.DocumentManager.doPost(DocumentManager.java:201) at com.commnav.sbh.servlets.CommnavServlet.doGet(CommnavServlet.java:170) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) 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.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at
Re: [JDBC] Need help with JDBC driver. Problem, - getExportedKeys
* Keve Mller [EMAIL PROTECTED] wrote: | | An initial version for get(Imported|Exported)Keys and getCrossReference is | available in jxDBCon (http://jxbdcon.sf.net) the file can be extracted Do you only concentrate on compliance or is performance important as well ? Have you done any performance test of your driver vs. the driver shipped with the PostgreSQL distribution ? There was also another driver posted here for PostgreSQL about 1.5 years ago by Sverre Huseby, that had interesting performance characteristics. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(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] Re: Escape Processing problems
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hmmm, after a little more testing, I fixed a problem with backslashes.
New code attached.
Tom.
On Thu, Aug 30, 2001 at 11:46:16AM +0900, Thomas O'Dowd wrote:
Hi all,
I found some time this morning to write and test a new EscapeSQL() method.
I didn't make a patch for the driver yet as I'd like to hear some
comments. It's a tad longer than the original code as it only replaces
escape codes which appear in the SQL code and not inside strings.
It's attached as a separate java program which you can run to test with
various strings. Let me know if you think it is okay. It seems to work
with what I've tested it with.
Example:
$ /usr/local/java/jdk1.3/bin/java esc insert into test values ({d '2000-12-01'},
'string of\\ \' {d }', {t '12:12:12'})
insert into test values ( '2000-12-01', 'string of\\ \' {d }', {t '12:12:12'})
Do you think we should expand it to handle the other codes like {t and {ts ?
The old routine only handles {d.
Tom.
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Escape Processing problems
Hi Bruce,
I guess that wasn't exactly a patch that I sent in but rather a test
program with the new routine embeded so that other people could try
it out easily.
I'll mail in the patch later. I'm a little distracted right now with
something else. For the moment just delete the patch that you added
to the unapplied list.
Cheers,
Tom.
On Tue, Sep 04, 2001 at 10:57:10AM -0400, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hmmm, after a little more testing, I fixed a problem with backslashes.
New code attached.
Tom.
On Thu, Aug 30, 2001 at 11:46:16AM +0900, Thomas O'Dowd wrote:
Hi all,
I found some time this morning to write and test a new EscapeSQL() method.
I didn't make a patch for the driver yet as I'd like to hear some
comments. It's a tad longer than the original code as it only replaces
escape codes which appear in the SQL code and not inside strings.
It's attached as a separate java program which you can run to test with
various strings. Let me know if you think it is okay. It seems to work
with what I've tested it with.
Example:
$ /usr/local/java/jdk1.3/bin/java esc insert into test values ({d
'2000-12-01'}, 'string of\\ \' {d }', {t '12:12:12'})
insert into test values ( '2000-12-01', 'string of\\ \' {d }', {t
'12:12:12'})
Do you think we should expand it to handle the other codes like {t and {ts ?
The old routine only handles {d.
Tom.
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
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
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
---(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] Re: Escape Processing problems
Patch removed at request of author. Will resubmit.
Hmmm, after a little more testing, I fixed a problem with backslashes.
New code attached.
Tom.
On Thu, Aug 30, 2001 at 11:46:16AM +0900, Thomas O'Dowd wrote:
Hi all,
I found some time this morning to write and test a new EscapeSQL() method.
I didn't make a patch for the driver yet as I'd like to hear some
comments. It's a tad longer than the original code as it only replaces
escape codes which appear in the SQL code and not inside strings.
It's attached as a separate java program which you can run to test with
various strings. Let me know if you think it is okay. It seems to work
with what I've tested it with.
Example:
$ /usr/local/java/jdk1.3/bin/java esc insert into test values ({d '2000-12-01'},
'string of\\ \' {d }', {t '12:12:12'})
insert into test values ( '2000-12-01', 'string of\\ \' {d }', {t '12:12:12'})
Do you think we should expand it to handle the other codes like {t and {ts ?
The old routine only handles {d.
Tom.
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
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 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] Read transactions don't work on 7.0.x db's Disregard my other
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
To all those who responded ,
Thanks for your response,
I have attached the test programs that I used in the form of text files. The
contents should be self evident. Please have a look and comment.
I used j2sdk1.3.1 down load to linux machine from sun.com as my java platform
and
And perl, v5.6.0 built for i386-linux.
The PostgreSQL driver for perl came from www.perl.org
The postgreSQL driver in jdbc7.0-1.2.jar
Barry Lind wrote:
Andy,
I would be interesting in knowing what version you did this test on,
what platform, and most importantly which JDK (and if the Sun JDK which
JVM: classic, hotspot client, hotspot server).
thanks,
--Barry
andy wrote:
Hi,
I ran a few bench marks on JAVA writing to a postgreSQL table using and
found that for the same number of records added to the table as a
similar PERL routine the following results :
PERL 39 seconds : JAVA 45 Seconds.
In a similar experiment where PERL and JAVA did treir output to the
screen and not to a table,
JAVA took 3 seconds and PERL 310 Seconds.
My conclusion is that the database driver to postgreSQL is still far
from efficient in the JAVA implementation.
Both tests were run on the same computer.
I would appreciate your comments and suggestions.
Andy Sewell
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
/*
Java bench mark against perl count to 100 000 000
*/
import java.io.*;
import java.util.*;
public class lp{
public lp() throws ClassNotFoundException, FileNotFoundException, IOException
{
int last = 1000;
GregorianCalendar day = new GregorianCalendar();
String time = day.getTime().toString();
int k=0;
for (int i=0; ilast ; i++) {
for (int p=0; plast ; p++) {k=1+p;System.out.println(k);}
}
GregorianCalendar day1 = new GregorianCalendar();
String time2 = day1.getTime().toString();
System.out.println(time);
System.out.println(time2 + \n + k);
}
public static void main(String[] args) {
try {
lp test = new lp();
}
catch (Exception ex) {
System.err.println(Exception : + ex);
ex.printStackTrace();
}
}
}
lp.pl
/*
Java equivalent
*/
import java.io.*;
import java.sql.*;
import java.util.*;
public class pg{
Connection conn;
Statement stmt;
public pg() throws ClassNotFoundException, FileNotFoundException, IOException,
SQLException
{
Class.forName(org.postgresql.Driver);
conn = DriverManager.getConnection(jdbc:postgresql:exkom, andy, );
conn.setAutoCommit(true);
stmt = conn.createStatement();
int last = 1;
int res = stmt.executeUpdate(delete from junk);
GregorianCalendar day = new GregorianCalendar();
String time = day.getTime().toString();
for (int i=0; ilast ; i++) {
// try {
res = stmt.executeUpdate(insert into junk values( + i + ));
//} catch (SQLException e) {
// System.out.println(e);
//}
}
GregorianCalendar day1 = new GregorianCalendar();
String time2 = day1.getTime().toString();
//String time3 = day.getTime().toString();
System.out.println(time);
System.out.println(time2);
//System.out.println(time3);
//res.close();
stmt.close();
conn.close();
}
public static void main(String[] args) {
try {
pg test = new pg();
}
catch (Exception ex) {
System.err.println(Exception : + ex);
ex.printStackTrace();
}
}
}
/**
$conn = Pg::connectdb(dbname=exkom);
die $conn-errorMessage unless PGRES_CONNECTION_OK eq $conn-status;
# print Enter a state code :;
# $state_code = STDIN;
# chomp $state_code;
$result = $conn-exec(delete from junk);
$end = 1;
$t0 = new Benchmark;
for ($i=1; $i $end; $i++) {
$result = $conn-exec(insert into junk values($i));
}
$t1 = new Benchmark;
$td = timediff($t1, $t0);
print the $end records took :, timestr($td) , \n
**/
pg.pl
---(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 : ? (question mark) characters
Barry Lind a écrit : Kovács Péter wrote: the driver what character set the backend is sending us? Can't it ask the backend dynamically? This is what it actually does, isn't it? (Based on what I usually see in the trace output on the backend.) I tested a unicode database with varchar(255) fields and hungarian accented characters and it worked just fine. (With PostgreSQL 7.2.1 I think.) Yes this is exactly what the driver does. It asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). thanks, --Barry Thanks for the answer. I am using a postgresql server rebuilt from a rawhide SRPM and I guess it is not enabled by default (I can't check cause I don't have the SRPM anymore on my hd...). It is a lot better to turn this option on by default though the current solution (setting the charset properties manually fit me very well for my own development). Quentin -- Quentin DELANCE e-mail : [EMAIL PROTECTED] ---(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] 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])
[JDBC] Why JDBC 1?
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
[JDBC] driver source code indentation
I suggest that the JDBC driver adopt PostgreSQL's indentation standards (see PostgreSQL developers FAQ, question 1). I see that some source files have used this standard, but the vast majority do not. We should have a standard for consistency and our own sanity if nothing else. Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: [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] error - NOTICE: current transaction...MORE DETAIL...
hello. yet another follow-on to my questions...is there a way to determine
whether i am going to get this NOTICE before i execute a query? check
some status code or something?
thanks
chris
-Original Message-
From: Chris Markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 04, 2001 1:40 PM
To: [EMAIL PROTECTED]; 'Postgres Jdbc (E-mail)'
Cc: [EMAIL PROTECTED]
Subject: RE: [JDBC] error - NOTICE: current transaction...MORE DETAIL...
hello. i have some more details on this problem...i found the reference to
calling rollback when you get this sort of error.
(http://fts.postgresql.org/db/mw/msg.html?mid=1030879)... i have started
doing that, but i am still getting the problem.
i have the setup shown below...i've learned that i can usually get around
the fastpath error if i try the query a few times...so i make it call up to
10 times if there is an error...the po.load() call runs the (SELECT
versionid, versionid, versioncomment, versionlabel, creatorid, documentid,
versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034272) query from the last message i
sent (see below)...if that throws an exception, i catch it, rollback, and
contine...i am still seeing the same behavior though...
public void loadComplex(User user) throws SBHException {
int iterations = 10;
try {
//## TODO:
//## occasionally get a fastpath exception here...try to
//## call load() as many as 10 times if there is an exception...
//## this is here only as a test...
//## chris markiewicz
int i = 0;
boolean exceptionfound = false;
boolean goodResult = false;
while (!goodResult i iterations) {
try {
i++;
dv = (DocumentVersion)po.load(versionid, user);
goodResult = true;
} catch (Exception e) {
System.out.println(SBHDocument.loadComplex exception
attempt:+i);
try {po.rollback(user);} catch (Exception e3) {...log
here...}
exceptionfound = true;
Log.log(SBHDocument.loadComplex attempt:+i);
Log.log(SBHDocument.loadComplex e:+e);
if (i == (iterations - 1)) {
throw e;
}
}
}
if (exceptionfound) {
...log here...
}
} catch (TransactionException te) {
throw te;
} catch (SBHSecurityException sse) {
throw sse;
} catch (SBHException sbe) {
throw sbe;
} catch (Exception e) {
throw new SBHException(e);
}
}
here is the log calling that query many times:
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: SELECT versionid, versionid, versioncomment, versionlabel,
creatorid, documentid, versionorder, datestamp, versioncontent FROM
document_version WHERE versionid = 1034277
NOTICE: current transaction is aborted, queries ignored until end of
transaction block
DEBUG: CommitTransactionCommand
chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of chris markiewicz
Sent: Tuesday, September 04, 2001 11:42 AM
To: Postgres Jdbc (E-mail)
Cc: [EMAIL PROTECTED]
Subject: [JDBC] error - NOTICE: current transaction is aborted, queries
ignored until end of transaction block
Hello.
I have been having problems with postgresql large objects...i have been
searching the archives of this group and i have posted a question or two
Re: [JDBC] driver source code indentation
I suggest that the JDBC driver adopt PostgreSQL's indentation standards (see PostgreSQL developers FAQ, question 1). I see that some source files have used this standard, but the vast majority do not. We should have a standard for consistency and our own sanity if nothing else. Glad someone brought this up. A while ago I wrote: I tried pgindent but it doesn't understand Java and made a mess of it. I used astyle with the options: $ astyle --style=java -j *.java I have the reformatted jdbc files at: ftp://candle.pha.pa.us/pub/postgresql/astyle_jdbc.tar.gz I must say it looks very good. Can people tak a look at that and see if they like it? I will work on astyle to find a format that matches the main code indenting. If you like it, I will indent just after we go beta. -- 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 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] driver source code indentation
I agree that this is needed. In fact I know Bruce wants to do something in this area. In fact he sent out a few months ago a sample of the code after it had been cleaned up by some tool. At the time no one seemed to be very interested. Going forward for 7.2 I think now is the time that something should be done. We need the equivalent of pgindent for java. 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 often end up viewing files in editors/viewers other than the one I normally code with. Having to worry about getting the tab settings correct so that the code is readable is a pain (and sometimes not possible depending on the editor). I have personally adopted in my java IDE of choice (JBuilder) to have the IDE automatically replace tabs with spaces for this reason. thanks, --Barry Liam Stewart wrote: I suggest that the JDBC driver adopt PostgreSQL's indentation standards (see PostgreSQL developers FAQ, question 1). I see that some source files have used this standard, but the vast majority do not. We should have a standard for consistency and our own sanity if nothing else. Liam ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
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] [GENERAL] Regarding Vacuumdb
On Tue, 28 Aug 2001, Bhuvaneswari wrote: hi, I am getting the following error while doing vacuumdb, ERROR: mdopen: couldn't open test1: No such file or directory vacuumdb: database vacuum failed on db1. We got this error a lot in 6.5. Usually it means your table has somehow been corrupted, and postgres doesn't want anything to do with it. It'll show up, and you can even select from it, but doing so will crash the back-end, and you can't run a vacuum or pg_dump on that database successfully. You'll have to do a table-by-table pg_dump, destroy the DB, and reimport everything. You'll have to rebuild the corrupted table from scratch, since you might not be able to dump it. Either way, it's a lot of work. Just be careful. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] [GENERAL] Regarding Vacuumdb
Shaun Thomas wrote: On Tue, 28 Aug 2001, Bhuvaneswari wrote: hi, I am getting the following error while doing vacuumdb, ERROR: mdopen: couldn't open test1: No such file or directory vacuumdb: database vacuum failed on db1. We got this error a lot in 6.5. Usually it means your table has somehow been corrupted, and postgres doesn't want anything to do with it. It'll show up, and you can even select from it, but doing so will crash the back-end, and you can't run a vacuum or pg_dump on that database successfully. Yes. This error was caused in older versions by doing something like: BEGIN; DROP TABLE test1; ABORT; The 6.5 version of PostgreSQL would remove the underlying file from the file system when DROP TABLE was executed, not when the transaction performed a commit, so the file was gone, but the entries in the system cataloge remained. This is fixed in newer versions. Hope that helps, Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] driver source code indentation
On Tue, Sep 04, 2001 at 12:43:21PM -0700, Barry Lind wrote: snip 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. Oh noo! Barry's stumbled over the tripwire of the Tab/Spaces flamewar trap! Everyone duck! More seriously, this was actually voted on some time ago. (Check the HACKERS archives) Since the JDBC source is well segregated from the rest of the tree, it can have a different style, but if you want to adopt the 'standard' style, I'd suggest going all the way. In the other hand, since you'll need to use a different tool to maintain the style (unless Bruce update his pgident to handle java ...) it'll never be completely the same, anyway. I'd image that the core developers will go with whatever the JDBC maintainers want. Ross ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[JDBC] Patch for jdbc2 ResultSet.java
Just some minor fixes to avoid duplicate function calls that were bugging me.
If rows is garunteed not to change then we can store the size in a final class
variable,
but I wasn't sure I could assume that.
*** ResultSet.java.orig Tue Sep 4 16:34:14 2001
--- ResultSet.java Tue Sep 4 16:45:20 2001
***
*** 134,140
{
//release resources held (memory for tuples)
if(rows!=null) {
- rows.setSize(0);
rows=null;
}
}
--- 134,139
***
*** 709,716
public int findColumn(String columnName) throws SQLException
{
int i;
!
! for (i = 0 ; i fields.length; ++i)
if (fields[i].getName().equalsIgnoreCase(columnName))
return (i+1);
throw new PSQLException (postgresql.res.colname,columnName);
--- 708,715
public int findColumn(String columnName) throws SQLException
{
int i;
! final int flen = fields.length;
! for (i = 0 ; i flen; ++i)
if (fields[i].getName().equalsIgnoreCase(columnName))
return (i+1);
throw new PSQLException (postgresql.res.colname,columnName);
***
*** 726,736
if (index==0)
throw new SQLException(Cannot move to index of 0);
//if index0, count from the end of the result set, but check
//to be sure that it is not beyond the first index
if (index0)
! if (index=-rows.size())
! internalIndex=rows.size()+index;
else {
beforeFirst();
return false;
--- 725,737
if (index==0)
throw new SQLException(Cannot move to index of 0);
+ final int rows_size = rows.size();
+
//if index0, count from the end of the result set, but check
//to be sure that it is not beyond the first index
if (index0)
! if (index rows_size)
! internalIndex = rows_size+index;
else {
beforeFirst();
return false;
***
*** 739,745
//must be the case that index0,
//find the correct place, assuming that
//the index is not too large
! if (index=rows.size())
internalIndex = index-1;
else {
afterLast();
--- 740,746
//must be the case that index0,
//find the correct place, assuming that
//the index is not too large
! if (index = rows_size)
internalIndex = index-1;
else {
afterLast();
***
*** 753,760
public void afterLast() throws SQLException
{
! if (rows.size() 0)
! current_row = rows.size();
}
public void beforeFirst() throws SQLException
--- 754,762
public void afterLast() throws SQLException
{
! final int rows_size = rows.size();
! if (rows_size 0)
! current_row = rows_size;
}
public void beforeFirst() throws SQLException
***
*** 967,973
public boolean isAfterLast() throws SQLException
{
! return (current_row = rows.size() rows.size() 0);
}
public boolean isBeforeFirst() throws SQLException
--- 969,976
public boolean isAfterLast() throws SQLException
{
! final int rows_size = rows.size();
! return (current_row = rows_size rows_size 0);
}
public boolean isBeforeFirst() throws SQLException
***
*** 982,995
public boolean isLast() throws SQLException
{
! return (current_row == rows.size() -1 rows.size() 0);
}
public boolean last() throws SQLException
{
! if (rows.size() = 0)
return false;
! current_row = rows.size() - 1;
this_row = (byte [][])rows.elementAt(current_row);
return true;
}
--- 985,1000
public boolean isLast() throws SQLException
{
! final int rows_size = rows.size();
! return (current_row == rows_size -1 rows_size 0);
}
public boolean last() throws SQLException
{
! final int rows_size = rows.size();
! if (rows_size = 0)
return false;
! current_row = rows_size - 1;
this_row = (byte [][])rows.elementAt(current_row);
return true;
}
***
*** 1480,1483
}
}
}
-
--- 1485,1487
--
Joseph Shraibman
[EMAIL PROTECTED]
Increase signal to noise ratio. http://www.targabot.com
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] driver source code indentation
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
Re: [JDBC] Troubles using German Umlauts with JDBC
[forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: 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 For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
Rene, I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: 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 For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(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 Disregard my other
Patch removed at Barry's request. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 4: Don't 'kill -9' the postmaster
