Skip to Main Content

DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Pro*C bug?

830854Jan 13 2011 — edited Jan 13 2011
I had the need to execute, inside a .pc, a function I have the synonym for, and the synonym points to the real function in another db through a dblink. The code fragment looks like

EXEC SQL EXECUTE
BEGIN
:returnvalue := A_FUNCTION(:account, :amount, sysdate);
END;
END-EXEC;

and the synonym was created as

create or replace synonym A_FUNCTION for THE_FUNCTION@A_DB;

Everything is fine apparently (we are able to call THE_FUNCTION through A_FUNCTION from e.g. Toad client)

Pro*C compiler "extra" options are userid=abc/abc@DB sqlcheck=semantics as required for SQL EXECUTE / END-EXEC (see below for more)


The Pro*C precompiler "explodes" without saying anything and leaving temporary files around:


Pro*C/C++: Release 11.2.0.1.0 - Production on Thu Jan 13 09:18:32 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

System default option values taken from: /oracle/app/product/11.2.0/client/precomp/admin/pcscfg.cfg

/oracle/app/product/11.2.0/client/bin/proc char_map=STRING define=IN_PROC mode=oracle userid=abc/abc@DB sqlcheck=semantics include=. include=/user/abc/include include=/oracle/app/product/11.2.0/client/precomp/public code=ANSI_C iname=src/file.pc oname=src/.proc/file.c lname=src/.proc/file.c.lis


(no more output from proc, it simply terminates...)

user:../home$ ls
... tpLaaacY.dcl tpMaaacY.cod tpNaaacY.cud


I would classify this as a severe bug.

The current solution is to create a "local" function that calls the other function, through the synonym or "directly" (both work):

create or replace LOCAL_FUNC ( ... ) RETURN ... IS
BEGIN
RETURN ( A_FUNCTION ( ... ) );
END;

If it is not possible to call a func through a synonym over a dblink, it should give an error; instead it crashes silently, leaving pieces behind,
as said.

I would prefer the other solution (having a synonym and calling it from code); what's the problem with this approach? Is a known bug? Is there another kind of workaround not involving a dummy function container?

Edited by: 827851 on Jan 13, 2011 1:52 AM

Edited by: 827851 on Jan 13, 2011 1:53 AM

Edited by: 827851 on Jan 13, 2011 1:56 AM
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Feb 10 2011
Added on Jan 13 2011
0 comments
380 views