I think you need the IN OUT that Adam mentioned.
When you connect via SQL*Plus and successfully run the procedure, are you
using the same username and password that is defined in the CF data
source? If so, then I do not think it is a permissions problem but I could
be wrong. If not, it might be a permissions problem. You could test this
by changing your CF code to specify the username and password in the stored
procedure call that you use when you successfully run the procedure in
SQL*Plus. I think this will override what is stored in the CF data source
definition (but I am not sure).
The only permission you need is EXECUTE on the package in Oracle. If you
can connect to Oracle via SQL*Plus as the user running the stored
procedure, you can execute 'select * from user_tab_privs' to see what
privileges that user is granted. If the user is granted execute directly
on the package, you will see an entry in that table. If the user is
granted execute via role, it is harder to figure out because you need to
look at the roles granted to the user (select * from user_role_privs) and
then what object privileges are granted to the roles (not a single SQL
statement).
HTH.
Janet.
At 01:49 PM 9/14/2004 -0400, you wrote:
>Janet,
>I have the snippet now from them. This is how it's currently defined
>(which looks like it's in line with what you posted aside from In Out):
>
>Type ReturnSet is ref cursor;
>Procedure testpckg(curReturnSet Out Returnset);
>
>They had switched it before to be In Out for me and I still had the same
>error. The one thing I did notice is they do not have it defined with a
>schema name, they just have:
>
>package Test01 is
>
>Type ReturnSet is ref cursor;
>
>Procedure testpckg(curReturnSet Out Returnset);
>
>Could that possible cause a permissions issue as Adam had alluded too?
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
