Thread: Crystal Reports / PostgreSQL
Hello,
I am currently trying to reach a PostgreSQL database using Crystal Reports v11. My goal is to design a simple report that I can call from the Java viewer. Using the BO Xtreme database example everything is fine, but when I flip the switch to remotely access a PostgreSQL db, a connection is created in the Database Expert, but no tables are displayed.
If I create a Command that has SQL like "select * from table XYZ", I do get results back, but I don't understand why I have to do this if CR designer won't show me the tables.
Also, every time I try to access my connection, it tells me that "This method is not yet implemented". It doesn’t tell me which method, though.
Can anyone shed some light on how to get PostgreSQL up and running with Crystal Reports v11? Should I switch to v10?
Setup:
Crystal Reports v11
PostgreSQL db
PostgreSQL driver pg74.215.jdbc3.jar
jdk1.4.2_06
Thanks!
kh
Kenneth Hutchinson wrote: > Also, every time I try to access my connection, it tells me that "This > method is not yet implemented". It doesn’t tell me which method, though. Don't you have a stack trace ? > Can anyone shed some light on how to get PostgreSQL up and running with > Crystal Reports v11? Should I switch to v10? Did you try with the latest JDBC driver ? > PostgreSQL db Which version ?
Yeah, I've tried several versions. I'm using the latest one for the current version of PG we are running (7.4). Right now I can ping the database in Crystal (though by using commands instead of being able to retrieve the tables). But when I run the report from a JSP (report viewer), the connection info doesn't work. Don't know if this is two difference issues or if both are related to weird driver behavior. -----Original Message----- From: Xavier Poinsard [mailto:xpoinsard@free.fr] Sent: Wednesday, February 09, 2005 10:43 AM To: pgsql-jdbc@postgresql.org Cc: Kenneth Hutchinson Subject: Re: [JDBC] Crystal Reports / PostgreSQL Kenneth Hutchinson wrote: > Also, every time I try to access my connection, it tells me that "This > method is not yet implemented". It doesn't tell me which method, though. Don't you have a stack trace ? > Can anyone shed some light on how to get PostgreSQL up and running with > Crystal Reports v11? Should I switch to v10? Did you try with the latest JDBC driver ? > PostgreSQL db Which version ? This message is intended only for the use of the individual(s) or entity to which it is addressed and may contain informationthat is privileged, confidential, and/or proprietary to RealPage and its affiliated companies. If the reader ofthis message is not the intended recipient, you are hereby notified that any dissemination, distribution, forwarding orcopying of this communication is prohibited without the express permission of the sender. If you have received this communicationin error, please notify the sender immediately and delete the original message.
Kenneth Hutchinson wrote: > Yeah, I've tried several versions. I'm using the latest one for the > current version of PG we are running (7.4). As stated in http://jdbc.postgresql.org/download.html : "Much care is taken to make newer driver releases work against older servers, so if you are having a problem and suspect it is the driver's fault, don't hesitate to try out the latest release on an older server." > > Right now I can ping the database in Crystal (though by using commands > instead of being able to retrieve the tables). But when I run the > report from a JSP (report viewer), the connection info doesn't work. > > Don't know if this is two difference issues or if both are related to > weird driver behavior. > > Kenneth Hutchinson wrote: > >>Also, every time I try to access my connection, it tells me that "This > > >>method is not yet implemented". It doesn't tell me which method, > > though. > Don't you have a stack trace ? > > >>Can anyone shed some light on how to get PostgreSQL up and running > > with > >>Crystal Reports v11? Should I switch to v10? > > > Did you try with the latest JDBC driver ? > > >>PostgreSQL db > > Which version ? >
On Wed, 9 Feb 2005, Xavier Poinsard wrote: > Kenneth Hutchinson wrote: > > Also, every time I try to access my connection, it tells me that "This > > method is not yet implemented". It doesn�t tell me which method, though. > > Don't you have a stack trace ? Right, without knowing what method is actually being called and failing it is tough to determine if a workaround is available or how much work it would be to implement the method. Kris Jurka
Kris Jurka wrote: > > Right, without knowing what method is actually being called and failing it > is tough to determine if a workaround is available or how much work it > would be to implement the method. I read in the code that the Uninmplemented exception was designed to reduce driver size, but would you consider a patch adding the name of the unimplemented function to the message ?
On Thu, 10 Feb 2005, Xavier Poinsard wrote: > I read in the code that the Uninmplemented exception was designed to > reduce driver size, but would you consider a patch adding the name of > the unimplemented function to the message ? > I don't know, it doesn't seem all that useful. Anyone doing real development will surely know what function they are calling and will have the stacktrace handy. If we find out that Crystal Reports or other applications only return the error message with no context then we should probably do something about it. For now I believe time would be better spent actually implementing these methods. Kris Jurka
Yes, please add this. Or have it write to a log or something. Usually an app has a details button that allows you to see a trace or something with more detail. What is provided is not sufficient. kh -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Xavier Poinsard Sent: Thursday, February 10, 2005 3:01 AM To: Kris Jurka Cc: pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Crystal Reports / PostgreSQL Kris Jurka wrote: > > Right, without knowing what method is actually being called and failing it > is tough to determine if a workaround is available or how much work it > would be to implement the method. I read in the code that the Uninmplemented exception was designed to reduce driver size, but would you consider a patch adding the name of the unimplemented function to the message ? ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq This message is intended only for the use of the individual(s) or entity to which it is addressed and may contain informationthat is privileged, confidential, and/or proprietary to RealPage and its affiliated companies. If the reader ofthis message is not the intended recipient, you are hereby notified that any dissemination, distribution, forwarding orcopying of this communication is prohibited without the express permission of the sender. If you have received this communicationin error, please notify the sender immediately and delete the original message.
Hi, Kenneth, Kenneth Hutchinson schrieb: > Yes, please add this. Or have it write to a log or something. Usually > an app has a details button that allows you to see a trace or something > with more detail. What is provided is not sufficient. I would say that it is on behalf of the app to present the Stacktrace of the NotImplementedException to the user. It is unwise for a driver to assume it can wildly write to stdout / stderr or wherever. Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
Attachment
Kris Jurka wrote: > > On Thu, 10 Feb 2005, Xavier Poinsard wrote: > > >>I read in the code that the Uninmplemented exception was designed to >>reduce driver size, but would you consider a patch adding the name of >>the unimplemented function to the message ? >> > > > I don't know, it doesn't seem all that useful. Anyone doing real > development will surely know what function they are calling and will have > the stacktrace handy. If we find out that Crystal Reports or other > applications only return the error message with no context then we should > probably do something about it. For now I believe time would be better > spent actually implementing these methods. Sure, but they are a lot of methods to implement and if we want to fix quickly the functions used by Crystal reports (for example), without stack trace, it is the only simple way. > > Kris Jurka > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
On Thursday 10 February 2005 11:05, Xavier Poinsard wrote: > > I don't know, it doesn't seem all that useful. Anyone doing real > > development will surely know what function they are calling and > > will have the stacktrace handy. If we find out that Crystal > > Reports or other applications only return the error message with > > no context then we should probably do something about it. For now > > I believe time would be better spent actually implementing these > > methods. > > Sure, but they are a lot of methods to implement and if we want to > fix quickly the functions used by Crystal reports (for example), > without stack trace, it is the only simple way. I haven't been following this thread very closely. Excuse me if I'm totally off base here. I assume you're talking about this method in org.postgresql.Driver: public static SQLException notImplemented() { return new PSQLException(GT.tr("This method is not yet implemented."), PSQLState.NOT_IMPLEMENTED); } I agree with Kris that there is no need to include the method name in the exception. It is already shown in the stack trace. However, you can easily patch this method so that it includes the caller's method name in its error message. All you have to do is peek one level up the stack trace.
On Thu, 10 Feb 2005, Xavier Poinsard wrote: > Sure, but they are a lot of methods to implement and if we want to fix > quickly the functions used by Crystal reports (for example), without > stack trace, it is the only simple way. > Well now that we know we can't get the stack trace from crystal reports I agree. Kris Jurka
On Thu, 10 Feb 2005, Vadim Nasardinov wrote: > However, you can easily patch this method so that it includes the > caller's method name in its error message. All you have to do is peek > one level up the stack trace. > I think this assumes you can use StackTraceElement which is a 1.4 JDK feature. Manual parsing seems error prone and a lot of work to solve a very minor issue. Kris Jurka
On Thursday 10 February 2005 14:15, Kris Jurka wrote: > I think this assumes you can use StackTraceElement which is a 1.4 > JDK feature. That would certainly help. > Manual parsing seems error prone and a lot of work to solve a very > minor issue. I agree that it's not worth the effort, however minimal that effort might be. Out of curiousity though, what makes it error-prone?
On Thu, 10 Feb 2005, Vadim Nasardinov wrote: > Out of curiousity though, what makes it error-prone? > Any ad-hoc parsing is easy to get wrong by forgetting corner cases. I'm not saying it can't be done correctly, just that we shouldn't bother. Kris Jurka
Kenneth Hutchinson wrote: > Yes, please add this. Or have it write to a log or something. Usually > an app has a details button that allows you to see a trace or something > with more detail. What is provided is not sufficient. If you set a log writer on java.sql.DriverManager, every java.sql.SQLException (or subclass e.g. PSQLException) will log a stack trace on construction. I actually find this more annoying than useful when debugging, but it's out of our control.. -O
Kris Jurka wrote: > > On Thu, 10 Feb 2005, Vadim Nasardinov wrote: > > >>Out of curiousity though, what makes it error-prone? >> > > > Any ad-hoc parsing is easy to get wrong by forgetting corner cases. I'm > not saying it can't be done correctly, just that we shouldn't bother. Especially given that different JVMs format stack traces differently, and Throwable.getStackTrace() is allowed to omit stack frames. I think setting a DriverManager log writer is the simplest solution here, closely followed by making notImplemented() take a method name arg. -O
On Thu, 10 Feb 2005, Kenneth Hutchinson wrote: > Yes, please add this. Or have it write to a log or something. Usually > an app has a details button that allows you to see a trace or something > with more detail. What is provided is not sufficient. > Xavier Poinsard has provided a patch to do this and I've put up new temporary jars if you'd like to retry: http://www.ejurka.com/pgsql/jars/kh/ Kris Jurka
On Thursday 10 February 2005 16:08, Oliver Jowett wrote: > > Any ad-hoc parsing is easy to get wrong by forgetting corner > > cases. I'm not saying it can't be done correctly, just that we > > shouldn't bother. > > Especially given that different JVMs format stack traces > differently, and Throwable.getStackTrace() is allowed to omit stack > frames. You're right as usual. Here's a somewhat off-topic example of when relying on stack traces backfires: http://weblog.ikvm.net/PermaLink.aspx?guid=245f4ca5-0512-4e66-a6c6-fa4d4af697ef