Re: Bug Report - Mailing list pgsql-jdbc
From | pedro farinha |
---|---|
Subject | Re: Bug Report |
Date | |
Msg-id | 1139280770.2693.58.camel@localhost.localdomain Whole thread Raw |
In response to | Re: Bug Report (Kris Jurka <books@ejurka.com>) |
Responses |
Re: Bug Report
|
List | pgsql-jdbc |
Hi,
Ralph make sure there is no older JDBC jar on the Sun Server class path. You maybe have a datasource/Data Server type defined referencing an older jar? look at the SAS Admin for JNDI and Datasources you probably will find something not 100% as you wanted there, or on Creator on Data Server type form.
On Creator make sure you delete the Data base server type and recreate using the newer jar, drop all of the defined datasources with the old DB Server type, and remove them from the Project (right on the bottom .... Data source references).
The most important thing though is to search for older versions of the jar in the Sun Server / glassfish, and make sure you delete it, all of them. ( if you use SAS8 or GlassFish they should be on <server>/lib) Then recreate the Data sources and add them to the project, build and deploy, this should add the required jar postgresql driver to the classpath of the server. A bit overkill? yes I also think so, but worked for me. I am 99.99% certain if you remove the old jar from the SAS classpath and add the new one( or redefine the DataServerType), it should do it. But hey, that was a transcript from my notes when I had to doit! Most important for run-time, is to make sure the older jar is not there, It is class-loading issue. The class loader will load the classes once, if it picks the old one first.....
I have found several problems using Postgresql and CachedRowSet, still not 100% if it is a driver problem or a Creator design problem, the bug you refer it is , I think, a Creator design problem, as postgresql adheres to the spec ( again on my view). One other issue, a bit more problematic (if not yet solved) is the setTransactionLevel(), while transaction in progress. I have overcome that, using a patch from (sorry mate can't remember you're name) but it basically cancels the exception ( turning it into a System.out.println('oops'), causing the "obvious" problems to go away. But there are others, I couldn't use CachedRowSet to insert and delete, so I dropped the use of CachedRowSet. Which is OK but not that OK! In the end of the day for real things you would need to create a DTO, and well, in that case you might want to use a Object*DataSource. And that model is really the correct approach, I think. On other hand if the only thing you want is to display a RecordSet in a table the new driver does the job.
Ok , a bit verbose sorry for that, in 1 line. Make sure no other jar but the one you want to use are on <server>/lib ;)!
On Mon, 2006-02-06 at 17:59, Kris Jurka wrote:
Ralph make sure there is no older JDBC jar on the Sun Server class path. You maybe have a datasource/Data Server type defined referencing an older jar? look at the SAS Admin for JNDI and Datasources you probably will find something not 100% as you wanted there, or on Creator on Data Server type form.
On Creator make sure you delete the Data base server type and recreate using the newer jar, drop all of the defined datasources with the old DB Server type, and remove them from the Project (right on the bottom .... Data source references).
The most important thing though is to search for older versions of the jar in the Sun Server / glassfish, and make sure you delete it, all of them. ( if you use SAS8 or GlassFish they should be on <server>/lib) Then recreate the Data sources and add them to the project, build and deploy, this should add the required jar postgresql driver to the classpath of the server. A bit overkill? yes I also think so, but worked for me. I am 99.99% certain if you remove the old jar from the SAS classpath and add the new one( or redefine the DataServerType), it should do it. But hey, that was a transcript from my notes when I had to doit! Most important for run-time, is to make sure the older jar is not there, It is class-loading issue. The class loader will load the classes once, if it picks the old one first.....
I have found several problems using Postgresql and CachedRowSet, still not 100% if it is a driver problem or a Creator design problem, the bug you refer it is , I think, a Creator design problem, as postgresql adheres to the spec ( again on my view). One other issue, a bit more problematic (if not yet solved) is the setTransactionLevel(), while transaction in progress. I have overcome that, using a patch from (sorry mate can't remember you're name) but it basically cancels the exception ( turning it into a System.out.println('oops'), causing the "obvious" problems to go away. But there are others, I couldn't use CachedRowSet to insert and delete, so I dropped the use of CachedRowSet. Which is OK but not that OK! In the end of the day for real things you would need to create a DTO, and well, in that case you might want to use a Object*DataSource. And that model is really the correct approach, I think. On other hand if the only thing you want is to display a RecordSet in a table the new driver does the job.
Ok , a bit verbose sorry for that, in 1 line. Make sure no other jar but the one you want to use are on <server>/lib ;)!
On Mon, 2006-02-06 at 17:59, Kris Jurka wrote:
On Mon, 6 Feb 2006, Ralph Moser wrote: > What i have meant is that in the Creator no error occours. With earlier > Versions of the driver the Creator reports also an error befor deploying the > app. (After draging a DB Table on a component) The 500DEV is the first > version wich alows me to drag a DB Table on a component. But if i deploy and > run the app I get the error i reportet before. I am 100% shure that i use > the correct driver at runtime. (Testet on an other PC with only the 500DEV > driver installed) Well, please send the complete stacktrace from this error and the datatypes of the table involved. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
pgsql-jdbc by date: