Re: 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



This message is intended only for the use of the individual(s) or entity to which it is addressed and may contain information that is privileged, confidential, and/or proprietary to RealPage and its affiliated companies. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, forwarding or copying of this communication is prohibited without the express permission of the sender. If you have received this communication in error, please notify the sender immediately and delete the original message.

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 doesnt 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

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(at)postgresql(dot)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

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 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