We recently upgraded our DB from 12c (12.1.0.2.0) to 19c(19.0.0.0.0) in EBS 12.1.3 environment on test instance. After upgrade I am unable to deploy custom web services using SOA rest services integration repository. I am getting following error on deployment:
Service Provider Access resulted in exception 'oracle.apps.fnd.isg.client.IREPException' when attempting to perform 'DEPLOY'. Please view Service Provider logs for more details
I reviewed log files but nothing informative found. One thing I noticed that I was able to deploy web services with simple out parameters with VARCHAR2 data type. But when there is an out parameter defined based on table type, I am receiving above mentioned error. I defined table type out parameter as follows which returns data in form of json array.
TYPE XRCL_TMS_PICKED_ORDERS1 IS TABLE OF ROCELL.XRCL_TMS_PICKED_ORDERS1%ROWTYPE INDEX BY BINARY_INTEGER;
It would be better to mention that on application with 12c database, web service can be deployed with no issue.
I resolved this problem by finding cause of collection type compatibility in 12c and 19c versions of databases.
In 12c below declaration of plsql collection type works fine:
TYPE type_name IS TABLE OF Table_Name%ROWTYPE INDEX BY BINARY_INTEGER;
but in 19c above declaration of plsql collection type has following error. I found this error after trying to recompile collection type:
PLS-00355: use of pl/sql table not allowed in this context
In 19c below declaration worked fine (created type as nested table):
CREATE TYPE type_name AS OBJECT
(
column_name datatype
);
CREATE TYPE type_name_nt AS TABLE OF type_name;
Related
I configured the jndi datasource and connected to the Oracle database, now I want to call the existing procedure named exampleProcedure that is stored there to fetch the data. I found this stackoverflow question that may be related to my issue, but how to store the incoming data?
I am working on an Azure Logic Apps integration which insert data into an on-premise Oracle Database.
I can successfully run the Logic Apps integration and insert the data into our Oracle table (a custom staging table).
I would like to run a truncate on that table before inserting the new data.
I added the Oracle - Execute a Oracle Query component and then provided the following query:
TRUNCATE TABLE .<TABLE_NAME>;
After deploying to Azure, the integration failed on the Execute a Oracle Query with error:
"message": "BadGateway",
"innerError": {
"status": 502,
"message": "Unable to find the requested .Net Framework Data Provider. It may not be installed.\r\n inner exception: Unable to find the requested .Net Framework Data Provider. It may not be installed....",
If I remove the Execute a Oracle Query component, the Oracle Insert row component works fine.
I am not sure why it says the gateway may not be installed. I suspect it's a badly trapped error message.
Is that how the Execute a Oracle Query is supposed to be used?
Otherwise, how can I execute the truncate or how can I debug this error message?
Thanks!
The Oracle Connector for Azure Logic Apps does not support DDL. The exception you are getting is the generic one in Azure Logic Apps. I honestly believe the exception handler module is not very reliable here, because it usually goes to the gateway issue when the problem has no relation whatsoever. However, you have the option to overcome this limitation by using a call to an stored procedure.
In Oracle
create or replace procedure pr_trc_table ( ptab in varchar2 )
is
begin
execute immediate 'truncate table '||ptab||' ' ;
exception when others then raise;
end;
/
This Oracle Connector developed by Microsoft has a lot of limitations, which is normal as they try to ensure you use their own Azure SQL Service.
When invoking a Stored Procedure on an Oracle server, we have the following limitations:
OUT parameters are not supported currently.
Return value is not available since Oracle Stored Procedure does not return any result.
Oracle Functions are not supported so they are not listed in the UI.
The response size limit is 8MB.
The request size limit is 2MB.
Oracle native query is supported with the following limitations:
RefCursor is not supported.
OUT parameters are not supported.
Only one result set can be returned.
Gateway version 3000.63.4 (October release) or later is required.
Minimum supported version for Oracle Data Access Client is version 11
Besides, if any oracle query or stored procedure execution time exceeds 110 seconds, the action will timeout. Insert and update to a table does not return the full item, it returns only the input properties for the operation. A Primary Key is required to get deterministic paging result for GetRows operation.
I created an SSIS package to copy data from one Oracle table to another Oracle table. Each table is in a different database.
I'm getting this error for every single column of the source table:
ERROR [HY010] [Oracle][ODBC]Function sequence error
This is the screenshot.
I have no idea what this means. I've also researched but I haven't seen anything that has helped me.
How can I fix this? I did read that an alternative is to create a linked server.
I wanted to add that the ODBC driver was created with a relatively recent Oracle 12 driver, so I'm not sure why VARCHAR2 columns would not be supported.
Also wanted to point out that the Windows server where the Oracle DB is 64-bit (Windows Server 2008) and Visual Studio 2008 (where the SSIS package is created) is 32-bit. That's why the driver has "_32" at the end.
Based on the following documentation:
The error occurs when ODBC functions are called out of the order required by the ODBC Specification.
The error can also occur if an ODBC function call returns an error and the application continues making ODBC calls that require the previous ODBC call to succeed.
I think you should check that all columns data types are supported by the ODBC driver.
Similar questions
MS-Oracle ODBC Driver Function Sequence Error
Update 1
You can refer to the following link to learn more about supported data types:
Oracle® Database Gateway for ODBC User's Guide - Data Type Conversion
Note that in the link above they mentioned that:
If a table contains a column whose data type is not supported by Oracle Database Gateway for ODBC, the column information is not returned to the Oracle database.
I have a database link set up to connect to an Oracle 11gR2 database from a Postgres 9.1 server. This uses OCI for the connection.
However, when I try to select any CLOB data I receive the following error:
ERROR: OCI error: ORA-01406: fetched column value was truncated
Is there anything that can be changed in the OCI to allow this to work correctly?
I am noticing that a lot of db's have trouble connecting to text fields in PostgreSQL. Is there a reason it has to be CLOB? Can you wrap in a function that would read the whole field?
My guess is that Oracle uses a streaming interface for CLOBs similar to the LOB postgresql interface but without the escaping. As a result PostgreSQL isnt really sure what to do with the value when it comes over.
I have a web app hosted on BEA Weblogic 10.x with an Oracle 10g database backend.
It works perfectly with one database, but when we make a clone of it and try to use a different WebLogic and Oracle instance we are getting this error:
ERROR - Problem initializing invocation tracking - disabling
tracking xxxxclass.BadTableMappingException: Database column
xxxxPeriodEnding in database yyyyyyy, table zzzzzzz has an
unknown type: JDBC Type 91.
We get it every time we do a query that involves a column of type DATE. There was no ORA-XXXX code in the message.
I can access the database using SQL*Plus using the same access and do selects and updates on the same tables with no errors.
The answer to this question is not just a simple description of what a type 91 error is (although that will help) but what could be causing this given the circumstances described above.
I am using ojdbc14.jar for JDBC on both instances of weblogic.
I have no idea about the error, but have you considered the jdbc jar version and more importantly if the oracle DB needs to be updated.
I faced very weird problems with oracle, and struggled for a while to find at the end that installing some patches for oracle would solve the problem.
Set oracle.jdbc.V8Compatible=true.
This remaps the oracle DATE type to a DATETIME time in JDBC. This parameter was missing on the new Weblogic server.