i try to get some records from DB Package (ORTAK.MERNIS) using its function (GETMERNISINFO(v_var number)) into PLL package type (MERNISLIB.MERNIS_USER).
But I ve a trouble with sending parameter to db package function (:TCK). It throws ORA-01008 : Not all variables bound
If I set function parameter statically (ORTAK.MERNIS.GETMERNISINFO(12345678)), it works as expected.
I use that code in Oracle Forms 6i
Any Ideas?
declare
MUSER MERNISLIB.MERNIS_USER;
begin
SELECT TCK,ADI,SOYADI INTO MUSER from table(cast(ORTAK.MERNIS.GETMERNISINFO(:TCK) as ORTAK.TCKTABLE));
:ADI := MUSER.ADI;
:SOYADI := MUSER.SOYADI;
end;
Looks like tck is coming from a text input item on the form. Can you try and fully qualify it as :block_name.item_name.
A library can't see the form items :ADI and :SOYADI because there is no guarantee the form the library is attached to will have them.
Use the COPY and NAME_IN functions to populate, or read form block items in a library procedure.
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 facing a problem where in my package another package.procedure is called which has one IN parameter and one OUT parameter (number datatype).
Now this called procedure is declared as PRAGMA AUTONOMOUS TRANSACTION and in execution block the OUT parameter is set to say po_value := 1;. After this there is some processing (in this we not setting OUT parameter anywhere) and finally in the EXCEPTION section, in WHEN OTHERS we setting OUT parameter to say po_value := 0;
I am doing some further processing with this OUT parameter in my calling main procedure i.e If po_value =1 then some processing happens.
Here is my problem. Using Debugger I am passing some value to main proc and when it called another proc (as mentioned above) the OUT parameter value is shown as NULL in debugger's Smart Data tab. I am expecting it should either 1 or 0 and not NULL. So is pragma autonomous_transactioncausing any problem (which I don't think should but as I see no other reason I have doubts on it)?
Please suggest.
I am trying to compile an Oracle package that my colleague left to me. However, the package spec. contains some functions that may not be built in my Oracle environment.
create or replace PACKAGE AAA IS
g_session VARCHAR2(400) := v('SESSION');
g_user VARCHAR2(400) := v('APP_USER');
PROCEDURE p_1;
END AAA;
When I try to compile the package spec in Oracle developer, I states
'V' must be declared.
Since the colleague that left me this code is no longer available, I have no idea of how to compile them.
The v function is meaningful in Apex environment; it'll return the value of the parameter you pass to it. In your example, that would be something like this:
v('SESSION') = 32604633949883 --> session ID
v('APP_USER') = LITTLEFOOT --> user logged to Apex
Apart from Apex environment, the v function works from your named PL/SQL stored procedures, packages and such.
As you aren't capable of compiling that code, it seems that there's no Apex installed in the database that contains that package. Is there? If not, well, you won't be able to compile it so you can:
install Apex, or
remove the v function calls from your code
I have a java stored procedure that takes in a clob representing a chunk of javascript and mins it. The structure of the function calling the JSP is as follows:
function MIN_JS(pcl_js in clob) return clob as
language java name 'JSMin.min(oracle.sql.CLOB) return oracle.sql.CLOB';
In the actual JSP, I have the following:
import oracle.sql.CLOB;
public class JSMin {
...
public static min(CLOB js) {
...
}
The problem I'm having is that whenever I pass a clob to JS_MIN, it is always interpreted as null inside the JSP. I've checked the clob before calling JS_MIN annd it definitely has contents. Any ideas as to what I'm missing? Any help is greatly appreciated.
As it turns out, one of the javascript chunks I was sending was in fact null. We have several packages that generate javascript for various controls and one is apparently still under development and wrapped in a way that it always returns null unless you are logged in as a particular user.
In my code, I loop across all the javascript packages, sending each to JS_MIN. Everything was working peachy until the package still in development came along and passed null. I added a simple check for null and everything works perfectly now.
So the short answer is: Doh!
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.