We are trying to execute an oracle function that requires parameters and we are getting the error ORA-01008- Not all variables are bound. We are pretty sure the problem is in how we are binding the variable that is supposed to received the result of the function. First we tried the following (a method without parameters):
$tSql:="select staging.FUNC_ORAOCI_TEST() from dual"
$iStatus:=OCIHandleAlloc (envhp;$stmthp;OCI_HTYPE_STMT)
$iStatus:=OCIHandleAlloc (envhp;$errhp;OCI_HTYPE_ERROR)
$iStatus:=OCIStmtPrepare ($stmthp;$errhp;$tSql;OCI_DEFAULT)
$iStatus:=OCIDefineByPos ($stmthp;$bindpp;$errhp;1;->atResults;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;OCI_DEFAULT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
And it worked perfectly...
Where we got stuck was when trying to pass parameters to the function (which we had modified on purpose to now accept parameters)
We thought it was because we now had to make the binding by name, but it just did not work. We have tried running a PL/SQL block and still we get the error. Here are our failed attempts:
Using a SQL Statement:
$tSql:="select staging.FUNC_ORAOCI_TEST(:tParamText,:iParamNum) from dual"
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":tParamText";- >tParamText;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":iParamNum";->iParamNum;SQLT_INT;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIDefineByPos ($stmthp;$bindpp;$errhp;1;->atResults;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;OCI_DEFAULT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
Using a PL/SQL Anonymous Block:
$tSql:="DECLARE vResult VARCHAR2:=''; BEGIN vResult := FUNC_ORAOCI_TEST(:tParamText,:iParamNum); End;"
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":tParamText";->tParamText;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":iParamNum";->iParamNum;SQLT_INT;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_IN)
$iStatus:=OCIBindByName ($stmthp;$bindpp;$errhp;":vResult";->tResult;SQLT_STR;$ORANullIndicator;$ORANullLenArray;$ORANullReturnCodeArray;1;OCI_DEFAULT;BIND_OUT)
$iStatus:=OCIStmtExecute (svchp;$stmthp;$errhp;1;0;0;0;OCI_DEFAULT)
We have looked at similar questions but no one was trying to use the OCI interface to execute the function the way we are doing it.
We are coding in 4D so ignore the weird syntax. We just need guidance as to how build the statement and what would be the proper OCI command to reach a successful binding.
We partially resolved this issue.
We have got it to work only for SQL statements not for PL/SQL. But we got rid of the ORA-01008 error.
The code in case 1 referenced above works as is. We did some clean up of comments and lines that were added for debugging, but they might have altered the sqlstmt somehow, thus affecting the binds.
The code in case 2 now gives an error "Invalid SQL Statement" which we will open a new inquiry for in separate thread.
One very useful information that we found to help us resolve the initial inquiry can be found here:
https://docs.oracle.com/database/121/LNOCI/oci05bnd.htm#LNOCI16368
Related
in oracle form builder my form does not access trigger named WNFI i call it on when- new- form-instance like this
execute_trigger('WNFI') ;
it doesn't enter it at all
what is the problem ?
Which Forms version do you use?
I've just tried it on Forms 10g, and it works OK - trigger is called and does its job (in my test, displays a message).
Anyway, just in case you didn't understand what APC says: move code from the WNFI trigger into a procedure (not a stored procedure, in the database; create it under the Program units node in the Object Navigator). For example:
-- This is P_WNFI procedure; this code was previously in WNFI trigger
message('wnfi');
message('wnfi');
Modify WHEN-NEW-FORM-INSTANCE trigger:
-- instead of
-- execute_trigger('WNFI');
-- use
p_wnfi;
If you open Forms Online Help system and search for execute_trigger, you'll see a note:
EXECUTE_TRIGGER is not the preferred method for executing a user-named trigger. Writing a user-named subprogram is the preferred method.
If I were you, I'd do as told. execute_trigger might be here for backward compatibility for some time, but not forever. Who knows; maybe Oracle corp. does.
I am getting the following error when running the report. Any idea why? This is a report which was working earlier but not sure what changed and it stopped working.
Error filling print... OUT paramater used in non-stored procedure call : ORACLE_REF_CURSOR class java.sql.ResultSet
Setting up the file resolver...
net.sf.jasperreports.engine.JRException: OUT paramater used in non-stored procedure call : ORACLE_REF_CURSOR class java.sql.ResultSet
at com.jaspersoft.jrx.query.PlSqlQueryExecuter.createStatement(PlSqlQueryExecuter.java:369)
at com.jaspersoft.jrx.query.PlSqlQueryExecuter.createDatasource(PlSqlQueryExecuter.java:113)
at net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(JRFillDataset.java:1086)
at net.sf.jasperreports.engine.fill.JRFillDataset.initDatasource(JRFillDataset.java:667)
at net.sf.jasperreports.engine.fill.JRBaseFiller.setParameters(JRBaseFiller.java:1258)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:877)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:822)
at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:61)
at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:446)
at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:276)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:745)
at com.jaspersoft.ireport.designer.compiler.IReportCompiler.run(IReportCompiler.java:891)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
Print not filled. Try to use an EmptyDataSource...
I resolved the problem by removing the ORACLE_REF_CURSOR argument from procedure call within the Jasper report.
The procedure call was like {call procedure1($P{param1}, $P{ORACLE_REF_CURSOR})} when it was throwing the above error. After removing the ORACLE_REF_CURSOR argument from the call, its working now. Here is how the procedure call looks like{call procedure1($P{param1})} in the report.
Funny thing is that the report was working before with the ORACLE_REF_CURSOR in the argument of the procedure, but suddenly started throwing the above error.
If somebody has more explanation on this problem then do please update the answer.
Im having the following problem with Delphi 7.
I try to use a DBchart to represent some data with a line diagram from a database.
I want the data to be loaded from an ADOQuery that gets activated at runtime thought. I can do it without problem with a query that has a static SQL value, but i find problems at setting the datasource at runtime.
I try to use
dbchart1.series[1].datasource:=ADOQuery3;
After i have created series1, but i get a "list index out of bounds" error.
Am i using the wrong command? I tried several others but failed.
Anyone can give some help with this?
Solved it with the following (after creating series1 at the DBGrid)
with series1 do
begin
datasource:=ADOquery;
xlabelssource:='field1';
YValues.Valuesource:='field2';
checkdatasource;
end;
I have a script that makes use of a package (PKG_MY_PACKAGE). I will change some of the fields in a query in that package and then recompile it (I don't change or compile any other packages). I run the script and I get an error that looks like
ORA-04068: existing state of packages has been discarded
ORA-04061: existing state of package body "USER3.PKG_MY_PACKAGE" has been invalidated
ORA-04065: not executed, altered or dropped package body "USER3.PKG_MY_PACKAGE"
ORA-06508: PL/SQL: could not find program unit being called: "USER3.PKG_MY_PACKAGE"
ORA-06512: at line 34
I run the script again (without changing anything else in the system) and the script executes successfully.
I thought that when I compiled before I executed the script that would fix any invalid references. This is 100% reproducible, and the more I use this script the more annoying it gets. What could cause this, and what would fix it?
(oracle 10g, using PL/SQL Developer 7)
Background
existing state of packages has been discarded means, that your Package had some sort of state.
This is caused by a global variable stored in your Package Body.
Until 11.2.0.2, constants did also cause this behavior (see documentation).
Since the package has already been used in your session, Oracle assumes that this state is relevant for you. Some of these variables might have different values now, and when you recompile the Body, the values are reset.
This exception is thrown, so that your clients know that they can't rely on those variables any more.
Solutions
Remove all global variables and constants (before 11gR2) from the Package Body if possible
Replace global variables by DETERMINISTIC functions (as suggested by this answer)
Defining packages with PRAGMA SERIALLY_REUSABLE causes Oracle to re-initialize the global variables with every call to the server.
Close your session and reconnect before calling the package again.
Reset the state manually (see Paul James' answer)
If you're running stuff in a script try these commands in there prior to running the re-compiled code..
exec DBMS_SESSION.RESET_PACKAGE
exec DBMS_SESSION.MODIFY_PACKAGE_STATE( DBMS_SESSION.REINITIALIZE )
They do what the name might suggest.
Possible issues you can have is:
The package/procedure you are calling is invalid (though it can work if called independently)
check this query whether you have an entry of your package or objects used in your package in this all_objects view
select * from all_objects where status = 'INVALID' and owner = 'SCHEMA_NAME';
Check your package is having global variables? if yes then check if those variable is not being changed by any other session preferable remove those global variables/use function
Run below script to compile all the objects in your schema
begin
dbms_utility.compile_schema('SCHEMA_NAME', false);
end;
Last option if none of the above works then remove all the procedures/function from your package, add new function and try to run your function from the trigger. check if this works then your package is in special lock. After adding a new function/proc it's state will be valid again and then you can add all your actual funcs/procs and remove the newly added function/proc.
The above error : ORA-06508: PL/SQL: could not find program unit being called.
is caused when an attempt was made to call a stored program that could not be found. The program may have been dropped or incompatibly modified, or have compiled with errors.
Check that all referenced programs, including their package bodies, exist and are compatible.
You can run this query to find invalid objects, which may cause the ORA-06508 error:
select
comp_id,
comp_name,
version,
status,
namespace,
schema
from
dba_registry;
Has anyone seen this error when trying to call an external C function from an Oracle query? I'm using Oracle 10g and get this error every time I try to call one of the two functions in the library. A call to the other function returns fine every time, though the function that works is all self-contained, no calls to any OCI* functions.
Here's the stored procedure that is used to call the failing C code:
CREATE OR REPLACE PROCEDURE index_procedure(text in clob, tokens in out nocopy clob, location_needed in boolean)
as language c
name "c_index_proc"
library lexer_lib
with context
parameters
(
context,
text,
tokens,
location_needed
);
Any help would be appreciated. Everything I've found on this error message says that the action to take is: Contact Oracle customer support.
Edit: I've narrowed it down to the point that I know that there is a segfault deep in libclntsh after I call OCILobTrim (to truncate it down to 0 length) on the tokens clob. Here is the code I've been using to call this procedure.
declare text CLOB; tokens CLOB;
begin
dbms_lob.createtemporary(tokens, TRUE);
dbms_lob.append(tokens, 'token');
dbms_lob.createtemporary(text, TRUE);
dbms_lob.append(text, '<BODY>Test Document</BODY>');
index_procedure(text, tokens, FALSE);
dbms_output.put_line(tokens);
end;
/
Is there something wrong with this setup that might be causing OCILobTrim problems?
It looks like this is one of those errors that essentially means any number of things could have gone wrong with the external procedure.
There is a known bug in 10.2.0.3, no idea if it's relevant:
ORA-28579 occurs when trying to select
data from a pipelined table function
implemented in "C" using the
ODCITable/ANYDATASET interface.
ODCITableDescribe works fine but
ODCITableFetch generates an ORA-28579
error.
I would suggest:
Look in the database server
trace directories, and the directory
where the external proc is located,
for any log or trace files generated
when the error occurs.
Instrument your external proc in
some way so that you can try to
trace its execution yourself.
Contact Oracle support
Well, an upgrade to 10.2.0.4 (was using 10.2.0.1) at least gave me an understandable error instead of a fairly useless core file and the ORA-28579.
It turns out that the code I was debugging was assuming that calling OCILobRead would return all of the data in one pass. This is the case for any client using a fixed width character set.
For clients using a variable width character set, this isn't the case, OCILobRead was actually reading part of the data and returning OCI_NEED_DATA and future calls to OCILobTrim and OCILobWrite were failing because of the still pending call to OCILobRead. The solution was to loop OCILobRead calls until OCI_NEED_DATA was no longer returned and we had all of the needed data in our buffer.
A call to OCIBreak also would have allowed the OCILobTrim and OCILobWrite functions to continue, though we wouldn't have had all of the needed input data.