Optional Parameter - Oracle Package Throws an Error

Question

Hi there,
I have an Oracle Package & it has a stored procedure with optional parameter. The calling code is in ColdFusion.
When I run my webpage the Oracle throws below error.
" [Macromedia][Oracle JDBC Driver][Oracle]ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments in call to 'GET_CONTRACT_BY_DYN_SQL' ORA-06550: line 1, column 7: PL/SQL: Statement ignored "
Calling Code (ColdFusion)
<cfstoredproc procedure="CONTRACTS_PKG.GET_CONTRACT_BY_DYN_SQL" datasource="#REQUEST.dsn#">
     <cfprocparam cfsqltype="CF_SQL_INTEGER" type="in" value="1" variable="P_CONTRACTID">     
     <cfprocresult name="qDataDynSQL" resultset="1">
</cfstoredproc>
<br>Dynamic SQL Query:
<cfdump var="#qDataDynSQL#" label="Dynamic SQL Query">
Oracle Package
create or replace
PACKAGE CONTRACTS_PKG AS
TYPE T_CURSOR IS REF CURSOR;
PROCEDURE GET_CONTRACT_BY_DYN_SQL(P_CONTRACTID IN NUMBER, P_COLS IN VARCHAR2 DEFAULT '*', IO_CURSOR IN OUT T_CURSOR);
END CONTRACTS_PKG;
create or replace
PACKAGE BODY CONTRACTS_PKG AS
-- Get Contract Using Dynamic SQL
PROCEDURE GET_CONTRACT_BY_DYN_SQL(P_CONTRACTID IN NUMBER, P_COLS IN VARCHAR2 DEFAULT '*', IO_CURSOR IN OUT T_CURSOR)
IS
V_CURSOR T_CURSOR;
V_SQL VARCHAR2(200);
BEGIN
IF p_contractid > 0 THEN
V_SQL := 'SELECT '|| P_COLS || ' FROM CONTRACTS WHERE contract_id = ' || P_CONTRACTID ;
ELSE
V_SQL := 'SELECT '|| P_COLS || ' FROM CONTRACTS';
END IF;
OPEN V_CURSOR FOR V_SQL;
IO_CURSOR := V_CURSOR;
END GET_CONTRACT_BY_DYN_SQL;
END CONTRACTS_PKG;
Does anyone knows why it throws an error? As you can see in the package header & body the parameter P_COLS has the default value as '*'.
Looking forward to hear from someone.
Thanks,
Hitesh Patel

Answer 1

931198 wrote:
I have an Oracle Package & it has a stored procedure with optional parameter. The calling code is in ColdFusion.
When I run my webpage the Oracle throws below error.Never mind the error - your approach is most definitely a candidate for Oracle WTF.
Nothing sane about this approach. Especially the decision not to use bind variables and slowing down cursor processing significantly by burning a lot more CPU cycles on hard parsing and fragmenting the SQL Shared Pool in the process.
Why not used MS Access instead? It is far more suited as a mickey mouse database for a goofy application?
Why am I badmouthing your approach to Oracle? Because that is exactly the primary cause, the #1 reason, for poor Oracle performance and run-time problems dealing with Shared Pool fragmentation. It is something that many Oracle experts blog about, talk about, write about. It is addressed in numerous books, Oracle documentation, and even Oracle Support Notes.
And despite the amount of information available on how to get the basics rights in using Oracle... this approach you are pursuing still refuses to die. So it deserves to be beaten with a lead pipe when it rears its ugly head here in this forum..