Stored Procedure not returning data

[organickarma]

Environment

CR 9. Oracle 10g . ODBC driver for oracle.

I am using a stored procedure that populates a temp table that is read into the report. When i use the native oracle driver to add the stored procedure I am able to see data without issues.

On using the ODBC I do not get any data and I have no idea what the reason is.

Checked permissions on all DB resources but all well. It does seem like a driver issue

The stored procedure itself is part of a package.
It shows up in the database expert as package.procedure
when I use the ODBC but shows up as procedure under the qualifiers tab when i use Oracle Native Driver.

Could this be the issue???

the procedure passes 4 parameters 2 string types and 2 oracle DATE types and an out ref cursor is used.

HELP!!

 

[Turkbear]

Hi,
Why bother with the ODBC connection? They are never as compatible with all the features of the Oracle database
as the Native one...







To Paraphrase:"The Help you get is proportional to the Help you give.."

 

[synapsevampire]

You should use Oracle Server (native) over ODBC, it's faster and usually works better.

You also elected NOT to share what ODBC driver you're using, and why you prefer it.

If you're going to use ODBC in CR 9, then you should be using the ODBC for Oracle supplied by Crystal, not the OPracle supplied ODBC driver.

Of course Oracle 10G came out after CR 9, so you should expect it to have issues in any case.

Upgrade or expect errors.

-k

 

[organickarma]

I agree, I personally prefer the native driver but my company uses the odbc oracle driver 5.1 for the reports.

The reports as such are deployed on a java based app with jdbc thin oracle driver for connectivity.

I hope this makes sense.

Can I just leave my crystalreport with the native driver?

 

[synapsevampire]

Sure, try leaving it.

Using the ODBC driver wasn't an assured test anyway since they use JDBC.

In either case, the products are not compatible, so if they complain, point out that they've chosen to use a slower form of connectivity, plus Oracle 10g was just a forecast in Larrys bank account when CR 9 came out.

-k

 

[organickarma]

Ok this is what my BO admin told me. We cannot leave the reports with the native driver because they would have to install the same on their server for the reports to run in the web based app. Which is why they are using ODBC in the first place. So that brings me back to problem 1. Could it be something in my store proc that is incompatible with ODBC but is A OK with Oracle.

 

[synapsevampire]

Uuuuh, the whole point of using native is that you don't need to configure anything as you do with ODBC...

It does have to use the DLL but you don't have configuration issues.

Sounds like a good time to upgrade Crystal and the admin

-k

 

[organickarma]

I don't think that's my call .. I am all for the XI upgrade tho. The dll still means something has to be installed and you know how it is with server maintainance teams *rolls eyes*

 

[synapsevampire]

The DLL is probably already installed anyway...

But I understand your point, there is no scale large enough to measure the laziness of some admins

-k

 

[organickarma]

Well thanks for the ideas..appreciate it. Any thoughts on whether it might be an issue with the stored proc itself which is causing my report to blow up with ODBC?

Rather what aspects of the stored proc should I be looking at?

A