Date/Time Format Stored Procedure Calls in ADVANCE MODE in JDBC ADAPTER

Hi Experts,
What is significance of Date/Time Format Stored Procedure Calls in ADVANCE MODE in JDBC ADAPTER.
Thanks,
ABDUR

I guess this would be applicable for the folowing formats - DATE, TIME, TIMESTAMP.
This is the correct link
http://help.sap.com/saphelp_nw04/helpdata/en/64/ce4e886334ec4ea7c2712e11cc567c/content.htm
Regards,
Prateek

Similar Messages

Execution Times of Stored Procedures Called from Other Stored Procedures

If I execute sys.dm_exec_procedure_stats, it will produce execution times of my stored procedures executed recently.
However, stored procedures called from other stored procedures do not show up.
Is there code that can return the execution times of stored procedures even though they are called from other stored procedures.

Look at the example. It is counting nested execution.
CREATE PROC z1SP AS SELECT * FROM Production.Product;
GO
CREATE PROC z2SP AS SELECT * FROM Production.Product WHERE Color is not null; EXEC z1SP;
GO
SELECT object_name(2002822197), object_name(2034822311);
--z1SP z2SP
EXEC z1SP; EXEC z2SP;
GO 10
SELECT * from sys.dm_exec_procedure_stats
database_id object_id type type_desc cached_time last_execution_time execution_count
16 2002822197 P SQL_STORED_PROCEDURE 2014-12-16 13:02:45.170 2014-12-16 13:02:46.717 20
16 2034822311 P SQL_STORED_PROCEDURE 2014-12-16 13:02:45.460 2014-12-16 13:02:46.687 10
Kalman Toth Database & OLAP Architect
SQL Server 2014 Database Design
New Book / Kindle: Beginner Database Design & SQL Programming Using Microsoft SQL Server 2014

Stored procedure call with REF CURSOR from JDBC

How can I call a SP with a REF CURSOR OUT parameter from JDBC?

This is a breeze.
CallableStatement oraCall = oraConn.prepareCall("BEGIN PKG_SOMETHING.RETURNS_A_SP(?);END;");
oraCall.registerOutParameter(1,oracle.jdbc.driver.OracleTypes.CURSOR);
oraCall.execute();
ResultSet rsServList = (ResultSet) oraCall.getObject(1);
... use ResultSet ...
rsServList.close();
oraCall.close();
slag

Remote Stored Procedure Call Dispatcher WEB WERVICE

Hello all,
Environment: Windows OS, Oracle 10g, mod_plsql
I am looking for solutions to the following problem:
A way to dispatch calls to stored procedures from client to server with a minimal impact on performance.
We are looking at two possible solutions:
1) Making a call to a Remote Stored Procedure Call Dispatcher (RSPCDispatcher) stored procedure through mod_plsql.
2) Making a call to a Remote Stored Procedure Call Dispatcher (RSPCDispatcher) stored procedure through a web service.
Solution 1) is not the preferred one as you may already know that mod_plsql will not be supported starting 12g.
Solution 2) is the one we prefer as we believe that web services will be ever more supported in the future. When we move to 11g we may turn this web service into a native one (avoiding overhead in the OC4J for hosting the web service etc.).
We are looking for code examples and information pointers of how we could implement this dispatcher as a stored procedure in a DB package. We know that the implementation should be similar to the one done for mod_plsql in the OWA schema but the code there is obfuscated, so we could not borrow ideas from there.
We are not sure how to deal with the generalization of the above stated problem. We need to be able to pass to this dispatcher the stored procedure package and name we are invoking, ordered list of parameters (or parameters map), and the transport strategy (XML, JSON, etc.).
Basically, we are notsure how to deal with the USING clause of the EXECUTE IMMEDIATE statement. We can dynamically generate the SQL statement corresponding to the stored procedure we want to call, but we are not sure how to bind the parameters we are passing?
Also, we know that EXECUTE IMMEDIATE may be slow sometimes. So if could avoid it, this could further improve performance.
Perhaps the run-time generalized stored procedure execution may not be what we are looking for?! Perhaps we should include several design-time steps?! What about a script that given a package name (or just a single stored procedure) would generate a wrapper package which stored procudures' names would correspond to their respective counterparts in the given package which would take two parameters - the list of parameters in some sort of format, and the transport (content delivery strategy) and would return the result in the given content delivery strategy?! This script may also define the XSD of the XML message a stored procedure is called with (the parameter map) as well as the XSD of the XML result the stored procedure returns. Also the script could generate client code with the given language strategy (Java, .NET, etc.) for calling the RSPCDispatcher web service.
We request the following from the Oracle community folks:
a) Please, give us any relevant information that could be helpful to resolve this problem.
b) Any resource of how to inspect stored procedures in a package, its parameters, parameter types and direction (IN, OUT, or INOUT), etc.
Thank you very much in advance.
Regards,
Georgi

Hello all,
Environment: Windows OS, Oracle 10g, mod_plsql
I am looking for solutions to the following problem:
A way to dispatch calls to stored procedures from client to server with a minimal impact on performance.
We are looking at two possible solutions:
1) Making a call to a Remote Stored Procedure Call Dispatcher (RSPCDispatcher) stored procedure through mod_plsql.
2) Making a call to a Remote Stored Procedure Call Dispatcher (RSPCDispatcher) stored procedure through a web service.
Solution 1) is not the preferred one as you may already know that mod_plsql will not be supported starting 12g.
Solution 2) is the one we prefer as we believe that web services will be ever more supported in the future. When we move to 11g we may turn this web service into a native one (avoiding overhead in the OC4J for hosting the web service etc.).
We are looking for code examples and information pointers of how we could implement this dispatcher as a stored procedure in a DB package. We know that the implementation should be similar to the one done for mod_plsql in the OWA schema but the code there is obfuscated, so we could not borrow ideas from there.
We are not sure how to deal with the generalization of the above stated problem. We need to be able to pass to this dispatcher the stored procedure package and name we are invoking, ordered list of parameters (or parameters map), and the transport strategy (XML, JSON, etc.).
Basically, we are notsure how to deal with the USING clause of the EXECUTE IMMEDIATE statement. We can dynamically generate the SQL statement corresponding to the stored procedure we want to call, but we are not sure how to bind the parameters we are passing?
Also, we know that EXECUTE IMMEDIATE may be slow sometimes. So if could avoid it, this could further improve performance.
Perhaps the run-time generalized stored procedure execution may not be what we are looking for?! Perhaps we should include several design-time steps?! What about a script that given a package name (or just a single stored procedure) would generate a wrapper package which stored procudures' names would correspond to their respective counterparts in the given package which would take two parameters - the list of parameters in some sort of format, and the transport (content delivery strategy) and would return the result in the given content delivery strategy?! This script may also define the XSD of the XML message a stored procedure is called with (the parameter map) as well as the XSD of the XML result the stored procedure returns. Also the script could generate client code with the given language strategy (Java, .NET, etc.) for calling the RSPCDispatcher web service.
We request the following from the Oracle community folks:
a) Please, give us any relevant information that could be helpful to resolve this problem.
b) Any resource of how to inspect stored procedures in a package, its parameters, parameter types and direction (IN, OUT, or INOUT), etc.
Thank you very much in advance.
Regards,
Georgi

Calling Stored Procedure from Oracle DataBase using Sender JDBC (JDBC-JMS)

Hi All,
We have requirement to move the data from Database to Queue (Interface Flow: JDBC -> JMS).
Database is Oracle.
*Based on Event, data will be triggered into two tables: XX & YY. This event occurs twice daily.
Take one field: 'aa' in XX and compare it with the field: 'pp' in YY.
If both are equal, then
if the field: 'qq' in YY table equals to "Add" then take the data from the view table: 'Add_View'.
else if the field: 'qq' in YY table equals to "Modify" then take the data from the view table: 'Modify_View'.
Finally, We need to archive the selected data from the respective view table.*
From each table, data will come differently, means with different field names.
I thought of call Stored Procedure from Sender JDBC Adapter for the above requirement.
But I heard that, we cannot call stored procedure in Oracle through Sender JDBC as it returns Cursor instead of ResultSet.
Is there any way other than Stored Procedure?
How to handle Data Types as data is coming from two different tables?
Can we create one data type for two tables?
Is BPM required for this to collect data from two different tables?
Can somebody guide me on how to handle this?
Waiting eagerly for help which will be rewarded.
Thanks and Regards,
Jyothirmayi.

Hi Gopal,
Thank you for your reply.
>Is there any way other than Stored Procedure?
Can you try configuring sender adapter to poll the data in intervals. You can configure Automatic TIme planning (ATP) in the sender jdbc channel.
I need to select the data from different tables based on some conditions. Let me simplify that.
Suppose Table1 contains 'n' no of rows. For each row, I need to test two conditions where only one condition will be satisfied. If 1st condition is satisfied, then data needs to be taken from Table2 else data needs to be taken from Table3.
How can we meet this by configuring sender adapter with ATP?
================================================================================================
>How to handle Data Types as data is coming from two different tables?
If you use join query in the select statement field of the channel then whatever you need select fields will be returned. This might be fields of two tables. your datatype fields are combination of two diff table.
we need to take data only from one table at a time. It is not join of two tables.
================================================================================================
Thanks,
Jyothirmayi.

DML visibility in stored procedures called via JDBC

Hello,
I have two stored procedures, A and B. Proc A inserts Q into table X. Proc B selects Q from table X to insert it into table Y. Neither procedure does a COMMIT.
My Java class executes Proc A and then Proc B within a transaction (autocommit is false). But Proc B fails to select Q from table X with the No Data Found error, apparently unable to see the recently inserted Q.
If these two procedures are called from a SQL*Plus block, everything succeeds.
Does anyone have a clue about what I am missing? All my DML should be visible to my session.
Thank you in advance for any suggestions.
- CJ

Thank you, Joe, for your reply!
To the best of my knowledge, all of my stored procedure calls are being made from the same connection so I can rollback everything if necessary. I have not explicitly closed the connection between calls. The debugger indicates my connection session id never changes across calls.
Do you know of any JDBC trace tools that might help me verify my connections? I've enabled logging with oracle.jdbc.driver.OracleLog.setTrace(true) but it doesn't really give me specific connection information - at least not that I can tell. :)
Thanks!
Cori

Structure for Stored Procedure Call

Hi All,
Guys I am trying to call a stored procedure call using receiver jdbc adapter...
This is the outgoing message:
<b><?xml version="1.0" encoding="UTF-8" ?>
- <ns0:SP_DB xmlns:ns0="urn:sce-com:xi:dev:mohammf">
- <Test>
- <PP_TEST_P action="EXECUTE">
<table>PP_TEST_P</table>
<RECTYPEIND type="CHAR">CC</RECTYPEIND>
<JENUMBER type="CHAR">76724</JENUMBER>
<COMPANY type="CHAR">BCEO</COMPANY>
<CONSTANT1 type="CHAR">AB</CONSTANT1>
<SYSTEMDATE type="CHAR">08/12/2007</SYSTEMDATE>
<DR_CR_ID type="CHAR">0</DR_CR_ID>
<AMOUNT type="CHAR">934928599475843</AMOUNT>
<MONTH_NUMBER type="CHAR">000008</MONTH_NUMBER>
<COST_CENTER type="CHAR">LosAngeles</COST_CENTER>
<ORDERNO type="CHAR">694950375830</ORDERNO>
<WBS type="CHAR">Southern California Edis</WBS>
<ACCOUNTID type="CHAR">6949503758</ACCOUNTID>
<BATCH_ID type="CHAR">3408102007</BATCH_ID>
<ASSIGNMENT type="CHAR">Technology Solutio</ASSIGNMENT>
<GL_JOURNAL_CATEGORY type="CHAR">GHTF</GL_JOURNAL_CATEGORY>
<PROFIT_CENTER type="CHAR">3434694950</PROFIT_CENTER>
<REFDOCNUMBER type="CHAR">00000000004304300056006056</REFDOCNUMBER>
</PP_TEST_P>
- <PP_TEST_P action="EXECUTE">
<table>PP_TEST_P</table>
<RECTYPEIND type="CHAR">XX</RECTYPEIND>
<JENUMBER type="CHAR">76724</JENUMBER>
<COMPANY type="CHAR">BCEO</COMPANY>
<CONSTANT1 type="CHAR">AB</CONSTANT1>
<SYSTEMDATE type="CHAR">08/12/2007</SYSTEMDATE>
<DR_CR_ID type="CHAR">0</DR_CR_ID>
<AMOUNT type="CHAR">934928599475843</AMOUNT>
<MONTH_NUMBER type="CHAR">000008</MONTH_NUMBER>
<COST_CENTER type="CHAR">LosAngeles</COST_CENTER>
<ORDERNO type="CHAR">694950375830</ORDERNO>
<WBS type="CHAR">Southern California Edis</WBS>
<ACCOUNTID type="CHAR">6949503758</ACCOUNTID>
<BATCH_ID type="CHAR">3408102007</BATCH_ID>
<ASSIGNMENT type="CHAR">Technology Solutio</ASSIGNMENT>
<GL_JOURNAL_CATEGORY type="CHAR">GHTF</GL_JOURNAL_CATEGORY>
<PROFIT_CENTER type="CHAR">3434694950</PROFIT_CENTER>
<REFDOCNUMBER type="CHAR">00000000004304300056006056</REFDOCNUMBER>
</PP_TEST_P>
</Test>
</ns0:SP_DB></b>
The error I am getting is:
<b><i>2007-08-20 09:44:05 Error Unable to execute statement for table or stored procedure. 'PP_TEST_P' (Structure 'Test') due to java.sql.SQLException: ERROR: Invalid XML document format for stored procedure: 'type="<SQL-type>"' attribute is missing for element 'table' (Setting a SQL-type (e.g. INTEGER, CHAR, DATE etc.) is mandatory !)
2007-08-20 09:44:05 Error JDBC message processing failed; reason Error processing request in sax parser: Error when executing statement for table/stored proc. 'PP_TEST_P' (structure 'Test'): java.sql.SQLException: ERROR: Invalid XML document format for stored procedure: 'type="<SQL-type>"' attribute is missing for element 'table' (Setting a SQL-type (e.g. INTEGER, CHAR, DATE etc.) is mandatory !)
2007-08-20 09:44:05 Error MP: Exception caught with cause com.sap.aii.af.ra.ms.api.RecoverableException: Error processing request in sax parser: Error when executing statement for table/stored proc. 'PP_TEST_P' (structure 'Test'): java.sql.SQLException: ERROR: Invalid XML document format for stored procedure: 'type="<SQL-type>"' attribute is missing for element 'table' (Setting a SQL-type (e.g. INTEGER, CHAR, DATE etc.) is mandatory !)
2007-08-20 09:44:05 Error Exception caught by adapter framework: null
2007-08-20 09:44:05 Error Delivery of the message to the application using connection JDBC_http://sap.com/xi/XI/System failed, due to: com.sap.aii.af.ra.ms.api.RecoverableException: Error processing request in sax parser: Error when executing statement for table/stored proc. 'PP_TEST_P' (structure 'Test'): java.sql.SQLException: ERROR: Invalid XML document format for stored procedure: 'type="<SQL-type>"' attribute is missing for element 'table' (Setting a SQL-type (e.g. INTEGER, CHAR, DATE etc.) is mandatory !).</i></b>
Pls advice..
XIer
Message was edited by:
XIer

Hi,
Check your DATA TYPE attributes with the attributes of the column names in the Database table. There is a mismatch between the DT and Table in the database.
<b>Cheers,
*RAJ*</b>

Read data from a Stored Procedure in Android

I have a Stored Procedure say CustOrdersDetail. I have created a MBO for it in the workspace and deployed it on SAP Mobile Server. I am unable to read data from the stored procedure in code of the Android Application. If I pass a default load argument, then I am able to read data using findAll method. How to get the data from the stored procedure by passing it an argument in the Android Code ?
Message was edited by: Abhijit Kadam

Currently I am trying to call the stored procedure and retrieve the results. The stored procedure accepts 'orderId' as an argument and fetches the Product and Order Details.

How can I return a big amount of data from a stored procedure?

How can I return a big amount of data from a stored procedure in a efficient way ?
For example not using a cursor for going through all the rows and then assign the values to variables.
thanks in advance!

Let's see if I'm able to explain myself..
I have a SQL query with..about 190.000 (in the best fo the the options)
I have something like this in my stored procedure..
FOR REC IN trn_adj_no
LOOP
REC_PIPE.INSTANCE_ID:=REC.INSTANCE_ID;
REC_PIPE.PROCESS_ID:=REC.PROCESS_ID;
REC_PIPE.ENTITY_TYPE:='TRANSACTION';
REC_PIPE.CRES_FILENAME:=REC.CRES_FILENAME;
REC_PIPE.CHUNK_REVISION_SK:=P_CHUNK_REVISION_SK;
REC_PIPE.CHUNK_ID:=trim(p_chunk_id);
REC_PIPE.FCL_SK:=REC.FCL_SK;
REC_PIPE.FCL_TRADE_SK:=REC.FCL_TRADE_SK;
REC_PIPE.FCL_VALUATION_SK:=REC.FCL_VALUATION_SK;
REC_PIPE.FCL_BUSINESS_GROUP:=REC.FCL_BUSINESS_GROUP;
REC_PIPE.ABS_TRN_CD:=REC.ABS_TRN_CD;
REC_PIPE.ACC_INTEREST_IMP_LOAN_CCY_IFRS:=REC.ACC_INTEREST_IMP_LOAN_CCY_IFRS;
REC_PIPE.ACC_INTEREST_IMP_LOAN_IFRS:=REC.ACC_INTEREST_IMP_LOAN_IFRS;
REC_PIPE.ACCRUED_INT_AMT:=REC.ACCRUED_INT_AMT;
REC_PIPE.ACCRUED_INT_CCY_CD:=REC.ACCRUED_INT_CCY_CD;
REC_PIPE.AMORT_ID:=REC.AMORT_ID;
REC_PIPE.AMORT_IND:=REC.AMORT_IND;
REC_PIPE.ATI:=REC.ATI;
REC_PIPE.ATI_2:=REC.ATI_2;
REC_PIPE.ATI_2_AMT:=REC.ATI_2_AMT;
REC_PIPE.ATI_2_CCY_CD:=REC.ATI_2_CCY_CD;
REC_PIPE.ATI_AMT:=REC.ATI_AMT;
REC_PIPE.ATI_CCY_CD:=REC.ATI_CCY_CD;
REC_PIPE.AVG_MTH_DUE_AMT:=REC.AVG_MTH_DUE_AMT;
REC_PIPE.AVG_MTH_DUE_CCY_CD:=REC.AVG_MTH_DUE_CCY_CD;
REC_PIPE.AVG_YTD_DUE_AMT:=REC.AVG_YTD_DUE_AMT;
REC_PIPE.AVG_YTD_DUE_CCY_CD:=REC.AVG_YTD_DUE_CCY_CD;
REC_PIPE.BAL_SHEET_EXP_AMT:=REC.BAL_SHEET_EXP_AMT;
REC_PIPE.BAL_SHEET_EXP_AMT_IFRS:=REC.BAL_SHEET_EXP_AMT_IFRS;
REC_PIPE.BAL_SHEET_EXP_CCY_CD:=REC.BAL_SHEET_EXP_CCY_CD;
REC_PIPE.BAL_SHEET_EXP_CCY_CD_IFRS:=REC.BAL_SHEET_EXP_CCY_CD_IFRS;
REC_PIPE.BAL_SHEET_EXP_EUR_AMT:=REC.BAL_SHEET_EXP_EUR_AMT;
REC_PIPE.BAL_SHEET_EXP_EUR_AMT_IFRS:=REC.BAL_SHEET_EXP_EUR_AMT_IFRS;
REC_PIPE.BEN_CCDB_ID:=REC.BEN_CCDB_ID;
REC_PIPE.BEN_CD:=REC.BEN_CD;
REC_PIPE.BEN_SRC_CD:=REC.BEN_SRC_CD;
REC_PIPE.BOOK_CD:=REC.BOOK_CD;
REC_PIPE.BOOK_TYPE_CD:=REC.BOOK_TYPE_CD;
REC_PIPE.BOOK_VAL_AMT:=REC.BOOK_VAL_AMT;
REC_PIPE.BOOK_VAL_AMT_IFRS:=REC.BOOK_VAL_AMT_IFRS;
REC_PIPE.BOOK_VAL_CCY_CD:=REC.BOOK_VAL_CCY_CD;
REC_PIPE.BOOK_VAL_CCY_CD_IFRS:=REC.BOOK_VAL_CCY_CD_IFRS;
REC_PIPE.BOOK_VAL_US_GAAP_AMT:=REC.BOOK_VAL_US_GAAP_AMT;
REC_PIPE.BRANCH_ID:=REC.BRANCH_ID;
REC_PIPE.BRANCH_LOC_CD:=REC.BRANCH_LOC_CD;
REC_PIPE.BS_COMPEN_CD:=REC.BS_COMPEN_CD;
REC_PIPE.BUS_AREA_UBR_ID:=REC.BUS_AREA_UBR_ID;
REC_PIPE.CA_CD:=REC.CA_CD;
REC_PIPE.CAD_RISK_WEIGHT_PCT:=REC.CAD_RISK_WEIGHT_PCT;
REC_PIPE.CASH_SETTLE_IND:=REC.CASH_SETTLE_IND;
REC_PIPE.CLS_FLG:=REC.CLS_FLG;
REC_PIPE.COB_DT:=REC.COB_DT;
REC_PIPE.COL_AGMENT_SRC_CD:=REC.COL_AGMENT_SRC_CD;
REC_PIPE.CONSOLIDATION_PCT:=REC.CONSOLIDATION_PCT;
REC_PIPE.CONTRACT_AMT:=REC.CONTRACT_AMT;
REC_PIPE.CONTRACT_COUNT:=REC.CONTRACT_COUNT;
REC_PIPE.COST_UNSEC_WORKOUT_AMT:=REC.COST_UNSEC_WORKOUT_AMT;
REC_PIPE.CPTY_CCDB_ID:=REC.CPTY_CCDB_ID;
REC_PIPE.CPTY_CD:=REC.CPTY_CD;
REC_PIPE.CPTY_LONG_NAME:=REC.CPTY_LONG_NAME;
REC_PIPE.CPTY_SRC_PROXY_UBR_ID:=REC.CPTY_SRC_PROXY_UBR_ID;
REC_PIPE.CPTY_TYPE_CD:=REC.CPTY_TYPE_CD;
REC_PIPE.CPTY_UBR_ID:=REC.CPTY_UBR_ID;
REC_PIPE.CREDIT_LINE_NET_IND:=REC.CREDIT_LINE_NET_IND;
REC_PIPE.CRES_SYS_ID:=REC.CRES_SYS_ID;
REC_PIPE.CTRY_RISK_PROVISION_BAL_AMT:=REC.CTRY_RISK_PROVISION_BAL_AMT;
REC_PIPE.CUR_NOTIONAL_AMT:=REC.CUR_NOTIONAL_AMT;
REC_PIPE.CUR_NOTIONAL_CCY_CD:=REC.CUR_NOTIONAL_CCY_CD;
REC_PIPE.CUR_NOTIONAL_CCY_CD_IFRS:=REC.CUR_NOTIONAL_CCY_CD_IFRS;
REC_PIPE.CUR_NOTIONAL_AMT_IFRS:=REC.CUR_NOTIONAL_AMT_IFRS;
REC_PIPE.DB_ENTITY_TRANSFER_ASSETS_CD:=REC.DB_ENTITY_TRANSFER_ASSETS_CD;
REC_PIPE.DEAL_TYPE_CD:=REC.DEAL_TYPE_CD;
REC_PIPE.DECOMPOSITION_IDENTIFIER:=REC.DECOMPOSITION_IDENTIFIER;
REC_PIPE.DEF_LOAN_FEE_IFRS:=REC.DEF_LOAN_FEE_IFRS;
REC_PIPE.DEF_LOAN_FEE_USGAAP:=REC.DEF_LOAN_FEE_USGAAP;
REC_PIPE.DELIVERY_DT:=REC.DELIVERY_DT;
REC_PIPE.DERIV_NOT_DT:=REC.DERIV_NOT_DT;
REC_PIPE.DERIV_NOT_IND:=REC.DERIV_NOT_IND;
REC_PIPE.DESK:=REC.DESK;
REC_PIPE.DIVISION_UBR_ID:=REC.DIVISION_UBR_ID;
REC_PIPE.ENTITY_CCDB_ID:=REC.ENTITY_CCDB_ID;
REC_PIPE.FAC_CD:=REC.FAC_CD;
REC_PIPE.FAC_LIMIT_CD:=REC.FAC_LIMIT_CD;
REC_PIPE.FAC_LIMIT_SRC_CD:=REC.FAC_LIMIT_SRC_CD;
REC_PIPE.FAC_SRC_CD:=REC.FAC_SRC_CD;
REC_PIPE.FAIR_VAL_CD_IFRS:=REC.FAIR_VAL_CD_IFRS;
REC_PIPE.FED_CLASS_CD:=REC.FED_CLASS_CD;
REC_PIPE.FIRST_RISK_PROVISION_DT:=REC.FIRST_RISK_PROVISION_DT;
REC_PIPE.FV_IMP_LOSS_CRED_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_CCY_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_IFRS:=REC.FV_IMP_LOSS_CRED_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_YTD_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_CCY_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_YTD_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_IFRS;
REC_PIPE.GEN_RISK_PROVISION_BAL_AMT:=REC.GEN_RISK_PROVISION_BAL_AMT;
REC_PIPE.GL_PROFIT_CENTRE:=REC.GL_PROFIT_CENTRE;
REC_PIPE.GLOBAL_GL_CD:=REC.GLOBAL_GL_CD;
REC_PIPE.IFRS_POSITION:=REC.IFRS_POSITION;
REC_PIPE.IFRS_POSITION_AGGR:=REC.IFRS_POSITION_AGGR;
REC_PIPE.IMP_DT:=REC.IMP_DT;
REC_PIPE.IMP_METHOD_CD:=REC.IMP_METHOD_CD;
REC_PIPE.INT_COMPEN_CD:=REC.INT_COMPEN_CD;
REC_PIPE.INTER_IND:=REC.INTER_IND;
REC_PIPE.INTERCO_IND:=REC.INTERCO_IND;
REC_PIPE.INTERCO_IND_IFRS:=REC.INTERCO_IND_IFRS;
REC_PIPE.LOAN_PUR_FAIR_VAL_ADJ_AMT:=REC.LOAN_PUR_FAIR_VAL_ADJ_AMT;
REC_PIPE.LOCAL_GL_CD:=REC.LOCAL_GL_CD;
REC_PIPE.LOWEST_LEVEL_UBR_ID:=REC.LOWEST_LEVEL_UBR_ID;
REC_PIPE.LTD_FEES_TO_PRINCIPAL_AMT:=REC.LTD_FEES_TO_PRINCIPAL_AMT;
REC_PIPE.MA_CD:=REC.MA_CD;
REC_PIPE.MA_SPL_NOTE:=REC.MA_SPL_NOTE;
REC_PIPE.MA_SRC_CD:=REC.MA_SRC_CD;
REC_PIPE.MA_TYPE_CD:=REC.MA_TYPE_CD;
REC_PIPE.MAN_LINK_ID:=REC.MAN_LINK_ID;
REC_PIPE.MASTER_MA_CD:=REC.MASTER_MA_CD;
REC_PIPE.MATURITY_DT:=REC.MATURITY_DT;
REC_PIPE.MAX_OUT_AMT:=REC.MAX_OUT_AMT;
REC_PIPE.MAX_OUT_CCY_CD:=REC.MAX_OUT_CCY_CD;
REC_PIPE.MTM_AMT:=REC.MTM_AMT;
REC_PIPE.MTM_AMT_IFRS:=REC.MTM_AMT_IFRS;
REC_PIPE.MTM_CCY_CD:=REC.MTM_CCY_CD;
REC_PIPE.MTM_CCY_CD_IFRS:=REC.MTM_CCY_CD_IFRS;
REC_PIPE.NEW_RISK_PROVISION_AMT:=REC.NEW_RISK_PROVISION_AMT;
REC_PIPE.NON_PERF_IND:=REC.NON_PERF_IND;
REC_PIPE.NON_PERF_RCV_INT_AMT:=REC.NON_PERF_RCV_INT_AMT;
REC_PIPE.OPT_TYPE_CD:=REC.OPT_TYPE_CD;
REC_PIPE.ORIG_NOTIONAL_AMT:=REC.ORIG_NOTIONAL_AMT;
REC_PIPE.ORIG_NOTIONAL_CCY_CD:=REC.ORIG_NOTIONAL_CCY_CD;
REC_PIPE.ORIG_TRN_CD:=REC.ORIG_TRN_CD;
REC_PIPE.ORIG_TRN_SRC_CD:=REC.ORIG_TRN_SRC_CD;
REC_PIPE.OTHER_CUR_NOTIONAL_AMT:=REC.OTHER_CUR_NOTIONAL_AMT;
REC_PIPE.OTHER_CUR_NOTIONAL_CCY_CD:=REC.OTHER_CUR_NOTIONAL_CCY_CD;
REC_PIPE.OTHER_ORIG_NOTIONAL_AMT:=REC.OTHER_ORIG_NOTIONAL_AMT;
REC_PIPE.OTHER_ORIG_NOTIONAL_CCY_CD:=REC.OTHER_ORIG_NOTIONAL_CCY_CD;
REC_PIPE.OVERDUE_AMT:=REC.OVERDUE_AMT;
REC_PIPE.OVERDUE_CCY_CD:=REC.OVERDUE_CCY_CD;
REC_PIPE.OVERDUE_DAY_COUNT:=REC.OVERDUE_DAY_COUNT;
REC_PIPE.PAY_CONTRACT_AMT:=REC.PAY_CONTRACT_AMT;
REC_PIPE.PAY_CONTRACT_CCY_CD:=REC.PAY_CONTRACT_CCY_CD;
REC_PIPE.PAY_FWD_AMT:=REC.PAY_FWD_AMT;
REC_PIPE.PAY_FWD_CCY_CD:=REC.PAY_FWD_CCY_CD;
REC_PIPE.PAY_INT_INTERVAL:=REC.PAY_INT_INTERVAL;
REC_PIPE.PAY_INT_RATE:=REC.PAY_INT_RATE;
REC_PIPE.PAY_INT_RATE_TYPE_CD:=REC.PAY_INT_RATE_TYPE_CD;
REC_PIPE.PAY_NEXT_FIX_CPN_DT:=REC.PAY_NEXT_FIX_CPN_DT;
REC_PIPE.PAY_UL_SEC_TYPE_CD:=REC.PAY_UL_SEC_TYPE_CD;
REC_PIPE.PAY_UL_ISS_CCDB_ID:=REC.PAY_UL_ISS_CCDB_ID;
REC_PIPE.PAY_UL_MTM_AMT:=REC.PAY_UL_MTM_AMT;
REC_PIPE.PAY_UL_MTM_CCY_CD:=REC.PAY_UL_MTM_CCY_CD;
REC_PIPE.PAY_UL_SEC_CCY_CD:=REC.PAY_UL_SEC_CCY_CD;
REC_PIPE.PAY_UL_SEC_CD:=REC.PAY_UL_SEC_CD;
REC_PIPE.PCP_TRANSACTION_SK:=REC.PCP_TRANSACTION_SK;
REC_PIPE.PROD_AREA_UBR_ID:=REC.PROD_AREA_UBR_ID;
REC_PIPE.QUOTA_PART_AMT:=REC.QUOTA_PART_AMT;
REC_PIPE.RCV_CONTRACT_AMT:=REC.RCV_CONTRACT_AMT;
REC_PIPE.RCV_CONTRACT_CCY_CD:=REC.RCV_CONTRACT_CCY_CD;
REC_PIPE.RCV_FWD_AMT:=REC.RCV_FWD_AMT;
REC_PIPE.RCV_FWD_CCY_CD:=REC.RCV_FWD_CCY_CD;
REC_PIPE.RCV_INT_RATE:=REC.RCV_INT_RATE;
REC_PIPE.RCV_INT_RATE_TYPE_CD:=REC.RCV_INT_RATE_TYPE_CD;
REC_PIPE.RCV_INT_INTERVAL:=REC.RCV_INT_INTERVAL;
REC_PIPE.RCV_NEXT_FIX_CPN_DT:=REC.RCV_NEXT_FIX_CPN_DT;
REC_PIPE.RCV_UL_ISS_CCDB_ID:=REC.RCV_UL_ISS_CCDB_ID;
REC_PIPE.RCV_UL_MTM_AMT:=REC.RCV_UL_MTM_AMT;
REC_PIPE.RCV_UL_MTM_CCY_CD:=REC.RCV_UL_MTM_CCY_CD;
REC_PIPE.RCV_UL_SEC_CCY_CD:=REC.RCV_UL_SEC_CCY_CD;
REC_PIPE.RCV_UL_SEC_CD:=REC.RCV_UL_SEC_CD;
REC_PIPE.RCV_UL_SEC_TYPE_CD:=REC.RCV_UL_SEC_TYPE_CD;
REC_PIPE.REC_SEC_AMT:=REC.REC_SEC_AMT;
REC_PIPE.REC_SEC_CCY_CD:=REC.REC_SEC_CCY_CD;
REC_PIPE.REC_UNSEC_AMT:=REC.REC_UNSEC_AMT;
REC_PIPE.REC_UNSEC_CCY_CD:=REC.REC_UNSEC_CCY_CD;
REC_PIPE.RECON_CD:=REC.RECON_CD;
REC_PIPE.RECON_SRC_CD:=REC.RECON_SRC_CD;
REC_PIPE.RECOV_AMT:=REC.RECOV_AMT;
REC_PIPE.RECOVERY_FLAG:=REC.RECOVERY_FLAG;
REC_PIPE.REGULATORY_NET_IND:=REC.REGULATORY_NET_IND;
REC_PIPE.REL_RISK_PROVISION_AMT:=REC.REL_RISK_PROVISION_AMT;
REC_PIPE.RESPONSIBLE_BRANCH_CCDB_ID:=REC.RESPONSIBLE_BRANCH_CCDB_ID;
REC_PIPE.RESPONSIBLE_BRANCH_ID:=REC.RESPONSIBLE_BRANCH_ID;
REC_PIPE.RESPONSIBLE_BRANCH_LOC_CD:=REC.RESPONSIBLE_BRANCH_LOC_CD;
REC_PIPE.RESTRUCT_IND:=REC.RESTRUCT_IND;
REC_PIPE.RISK_END_DT:=REC.RISK_END_DT;
REC_PIPE.RISK_ENGINES_METHOD_USED:=REC.RISK_ENGINES_METHOD_USED;
REC_PIPE.RISK_MITIGATING_PCT:=REC.RISK_MITIGATING_PCT;
REC_PIPE.RISK_PROVISION_BAL_AMT:=REC.RISK_PROVISION_BAL_AMT;
REC_PIPE.RISK_PROVISION_CCY_CD:=REC.RISK_PROVISION_CCY_CD;
REC_PIPE.RISK_WRITE_OFF_AMT:=REC.RISK_WRITE_OFF_AMT;
REC_PIPE.RISK_WRITE_OFF_LIFE_DT_AMT:=REC.RISK_WRITE_OFF_LIFE_DT_AMT;
REC_PIPE.RT_BUS_AREA_UBR_ID:=REC.RT_BUS_AREA_UBR_ID;
REC_PIPE.RT_CB_CCDB_ID:=REC.RT_CB_CCDB_ID;
REC_PIPE.RT_COV_CD:=REC.RT_COV_CD;
REC_PIPE.RT_COV_SRC_CD:=REC.RT_COV_SRC_CD;
REC_PIPE.RT_COV_TYPE_CD:=REC.RT_COV_TYPE_CD;
REC_PIPE.RT_COV_TYPE_CD_IFRS:=REC.RT_COV_TYPE_CD_IFRS;
REC_PIPE.RT_TYPE_CD:=REC.RT_TYPE_CD;
REC_PIPE.RT_TYPE_CD_IFRS:=REC.RT_TYPE_CD_IFRS;
REC_PIPE.SENIORITY:=REC.SENIORITY;
REC_PIPE.SETTLE_STATUS_ID:=REC.SETTLE_STATUS_ID;
REC_PIPE.SETTLEMENT_CD:=REC.SETTLEMENT_CD;
REC_PIPE.SETTLEMENT_DT:=REC.SETTLEMENT_DT;
REC_PIPE.SOX_REF:=REC.SOX_REF;
REC_PIPE.SPE_IND:=REC.SPE_IND;
REC_PIPE.SPL_TREAT_IND_IFRS:=REC.SPL_TREAT_IND_IFRS;
REC_PIPE.SRC_PROD_TYPE_CD:=REC.SRC_PROD_TYPE_CD;
REC_PIPE.SRC_PROD_TYPE_CD_IFRS:=REC.SRC_PROD_TYPE_CD_IFRS;
REC_PIPE.SRC_PROXY_UBR_CD:=REC.SRC_PROXY_UBR_CD;
REC_PIPE.START_DT:=REC.START_DT;
REC_PIPE.STRATEGIC_LEND_IND:=REC.STRATEGIC_LEND_IND;
REC_PIPE.STRIKE_FWD_FUT_PRICE_AMT:=REC.STRIKE_FWD_FUT_PRICE_AMT;
REC_PIPE.STRIKE_FWD_FUT_PRICE_CCY_CD:=REC.STRIKE_FWD_FUT_PRICE_CCY_CD;
REC_PIPE.TERMINATION_LOAN_DT:=REC.TERMINATION_LOAN_DT;
REC_PIPE.TRAD_ASSET_CD_IFRS:=REC.TRAD_ASSET_CD_IFRS;
REC_PIPE.TRADE_DT:=REC.TRADE_DT;
REC_PIPE.TRADE_ENTITY_CCDB_ID:=REC.TRADE_ENTITY_CCDB_ID;
REC_PIPE.TRADE_ENTITY_LOC_CD:=REC.TRADE_ENTITY_LOC_CD;
REC_PIPE.TRADE_RELATED_IND:=REC.TRADE_RELATED_IND;
REC_PIPE.TRADE_STATUS:=REC.TRADE_STATUS;
REC_PIPE.TRADING_ENTITY_LOC_CD:=REC.TRADING_ENTITY_LOC_CD;
REC_PIPE.TRAN_MATCH_CD:=REC.TRAN_MATCH_CD;
REC_PIPE.TRN_CD:=REC.TRN_CD;
REC_PIPE.TRN_LINK_CD:=REC.TRN_LINK_CD;
REC_PIPE.TRN_SRC_CD:=REC.TRN_SRC_CD;
REC_PIPE.TRN_TYPE_CD:=REC.TRN_TYPE_CD;
REC_PIPE.TRN_VERSION:=REC.TRN_VERSION;
REC_PIPE.UL_DELIVERY_DT:=REC.UL_DELIVERY_DT;
REC_PIPE.UL_MATURITY_DT:=REC.UL_MATURITY_DT;
REC_PIPE.UNDLY_ISS_NAME:=REC.UNDLY_ISS_NAME;
REC_PIPE.UNEARNED_INCOME_CCY_CD:=REC.UNEARNED_INCOME_CCY_CD;
REC_PIPE.UNEARNED_INCOME_DIS_LOAN_AMT:=REC.UNEARNED_INCOME_DIS_LOAN_AMT;
REC_PIPE.US_GAAP_POSITION_AGGR:=REC.US_GAAP_POSITION_AGGR;
REC_PIPE.VALUATION_DT:=REC.VALUATION_DT;
REC_PIPE.XCHG_CTRY_CD:=REC.XCHG_CTRY_CD;
REC_PIPE.YEAR01_NOTIONAL_AMT:=REC.YEAR01_NOTIONAL_AMT;
REC_PIPE.YEAR02_NOTIONAL_AMT:=REC.YEAR02_NOTIONAL_AMT;
REC_PIPE.YEAR03_NOTIONAL_AMT:=REC.YEAR03_NOTIONAL_AMT;
REC_PIPE.YEAR04_NOTIONAL_AMT:=REC.YEAR04_NOTIONAL_AMT;
REC_PIPE.YEAR05_NOTIONAL_AMT:=REC.YEAR05_NOTIONAL_AMT;
REC_PIPE.YEAR06_NOTIONAL_AMT:=REC.YEAR06_NOTIONAL_AMT;
REC_PIPE.YEAR07_NOTIONAL_AMT:=REC.YEAR07_NOTIONAL_AMT;
REC_PIPE.YEAR08_NOTIONAL_AMT:=REC.YEAR08_NOTIONAL_AMT;
REC_PIPE.YEAR09_NOTIONAL_AMT:=REC.YEAR09_NOTIONAL_AMT;
REC_PIPE.YEAR10_NOTIONAL_AMT:=REC.YEAR10_NOTIONAL_AMT;
REC_PIPE.YTD_PL_TRADE_AMT:=REC.YTD_PL_TRADE_AMT;
REC_PIPE.FCL_VALIDATED_IND:=REC.FCL_VALIDATED_IND;
REC_PIPE.FCL_EXCLUDED_IND:=REC.FCL_EXCLUDED_IND;
REC_PIPE.FCL_SOURCE_SYSTEM:=REC.FCL_SOURCE_SYSTEM;
REC_PIPE.FCL_CREATE_TIMESTAMP:=REC.FCL_CREATE_TIMESTAMP;
REC_PIPE.FCL_UPDATE_TIMESTAMP:=REC.FCL_UPDATE_TIMESTAMP;
REC_PIPE.FCL_TRADE_LOAD_DATE:=REC.FCL_TRADE_LOAD_DATE;
REC_PIPE.FCL_VALUATION_LOAD_DATE:=REC.FCL_VALUATION_LOAD_DATE;
REC_PIPE.FCL_MATRIX_TRADE_TYPE:=REC.FCL_MATRIX_TRADE_TYPE;
REC_PIPE.PCP_GCDS_REVISION:=REC.PCP_GCDS_REVISION;
REC_PIPE.FCL_UTP_BOOK_CD:=REC.FCL_UTP_BOOK_CD;
REC_PIPE.FCL_MIS_RISK_BOOK_CD:=REC.FCL_MIS_RISK_BOOK_CD;
REC_PIPE.ALD_STATUS:=REC.ALD_STATUS;
REC_PIPE.FCAT_OPERATION:=REC.FCAT_OPERATION;
REC_PIPE.INTERNAL_INTRA_IND_IFRS:=REC.INTERNAL_INTRA_IND_IFRS;
REC_PIPE.FCL_USAGE_IND:=REC.FCL_USAGE_IND;
REC_PIPE.QUICK:=REC.QUICK;
REC_PIPE.SEDOL:=REC.SEDOL;
REC_PIPE.CUSIP:=REC.CUSIP;
REC_PIPE.ISIN:=REC.ISIN;
REC_PIPE.QUANTITY:=REC.QUANTITY;
REC_PIPE.RIC:=REC.RIC;
REC_PIPE.DESCRIPTION:=REC.DESCRIPTION;
REC_PIPE.RESET_DATE:=REC.RESET_DATE;
REC_PIPE.PRICE:=REC.PRICE;
REC_PIPE.EXCHANGERATE:=REC.EXCHANGERATE;
REC_PIPE.PARA_PROD_TYPE_ID:=REC.PARA_PROD_TYPE_ID;
REC_PIPE.EFF_INT_RATE:=REC.EFF_INT_RATE;
REC_PIPE.ORIG_FEE_UNREALISED_AMT:=REC.ORIG_FEE_UNREALISED_AMT;
REC_PIPE.ASSET_TYPE:=REC.ASSET_TYPE;
REC_PIPE.IMP_IND_IFRS:=REC.IMP_IND_IFRS;
REC_PIPE.NOT_AMT_REDEMPTION_TO_1YR:=REC.NOT_AMT_REDEMPTION_TO_1YR;
REC_PIPE.NOT_AMT_REDEMPTION_TO_5YR:=REC.NOT_AMT_REDEMPTION_TO_5YR;
REC_PIPE.NOT_AMT_REDEMPTION_OVER_5YR:=REC.NOT_AMT_REDEMPTION_OVER_5YR;
REC_PIPE.CASH_LTD:=REC.CASH_LTD;
REC_PIPE.CASH_LTD_CCY:=REC.CASH_LTD_CCY;
REC_PIPE.FCL_FACILITY_SK:=REC.FCL_FACILITY_SK;
REC_PIPE.DILUTION_RISK_CRITERIA:=REC.DILUTION_RISK_CRITERIA;
REC_PIPE.FCL_RMS_RUNID:=REC.FCL_RMS_RUNID;
REC_PIPE.BSTYPE:=REC.BSTYPE;
REC_PIPE.YTD_ACCR_DIV:=REC.YTD_ACCR_DIV;
REC_PIPE.YTD_DIV:=REC.YTD_DIV;
REC_PIPE.ACC_ADJ_YTD:=REC.ACC_ADJ_YTD;
REC_PIPE.FV_RLZD_PL:=REC.FV_RLZD_PL;
REC_PIPE.ITD_PL:=REC.ITD_PL;
REC_PIPE.YTD_RLZD_PL:=REC.YTD_RLZD_PL;
REC_PIPE.YTD_UNRLZD_PL:=REC.YTD_UNRLZD_PL;
REC_PIPE.TRN_BAS_LGD:=REC.TRN_BAS_LGD;
REC_PIPE.TRAD_YTD_RLZD_PL:=REC.TRAD_YTD_RLZD_PL;
REC_PIPE.TRAD_YTD_UNRLZD_PL:=REC.TRAD_YTD_UNRLZD_PL;
REC_PIPE.UNADJUSTED_PV:=REC.UNADJUSTED_PV;
REC_PIPE.UNADJUSTED_REALISED_PL:=REC.UNADJUSTED_REALISED_PL;
REC_PIPE.UNADJUSTED_UNREALISED_PL:=REC.UNADJUSTED_UNREALISED_PL;
REC_PIPE.GRC_PROD_TYPE_ID:=REC.GRC_PROD_TYPE_ID;
REC_PIPE.GRC_PROD_TYPE_ID_IFRS:=REC.GRC_PROD_TYPE_ID_IFRS;
REC_PIPE.CUR_FEE:=REC.CUR_FEE;
REC_PIPE.SEC_IND:=REC.SEC_IND;
REC_PIPE.INVEST_ASSETS_PORT:=REC.INVEST_ASSETS_PORT;
REC_PIPE.RISK_PROVISION_START_BAL_AMT:=REC.RISK_PROVISION_START_BAL_AMT;
REC_PIPE.GEN_RISK_PRV_START_BAL_AMT:=REC.GEN_RISK_PRV_START_BAL_AMT;
REC_PIPE.GEN_RISK_PROVISION_NEW:=REC.GEN_RISK_PROVISION_NEW;
REC_PIPE.GEN_RISK_PROVISION_REL:=REC.GEN_RISK_PROVISION_REL;
REC_PIPE.ACQUIRED_IND:=REC.ACQUIRED_IND;
REC_PIPE.CRED_NET_MNA:=REC.CRED_NET_MNA;
REC_PIPE.SEC_IFRS_VUE_ADJ:=REC.SEC_IFRS_VUE_ADJ;
REC_PIPE.YEAR00_NOTIONAL_AMT:=REC.YEAR00_NOTIONAL_AMT;
REC_PIPE.MAX_OVERDUE_DAYS:=REC.MAX_OVERDUE_DAYS;
REC_PIPE.MIS_CD:=REC.MIS_CD;
REC_PIPE.MULTINAME_POOL_SK:=REC.MULTINAME_POOL_SK;
REC_PIPE.MULTINAME_CHUNK_REVISION_SK:=REC.MULTINAME_CHUNK_REVISION_SK;
REC_PIPE.MTRX_CALC_CNTRL_EPE:=REC.MTRX_CALC_CNTRL_EPE;
REC_PIPE.MTRX_CALC_CNTRL_PFE:=REC.MTRX_CALC_CNTRL_PFE;
REC_PIPE.FCL_TE_VALIDATED_IND:=REC.FCL_TE_VALIDATED_IND;
REC_PIPE.PCP_TE_DYNAMIC_KEY:=REC.PCP_TE_DYNAMIC_KEY;
REC_PIPE.AVG_COST:=REC.AVG_COST;
REC_PIPE.SEC_LONG_NAME:=REC.SEC_LONG_NAME;
REC_PIPE.ISS_CTRY_CD:=REC.ISS_CTRY_CD;
REC_PIPE.RISK_REPORTING_UBR:=REC.RISK_REPORTING_UBR;
REC_PIPE.RISK_COVERING_BRANCH_CCDB:=REC.RISK_COVERING_BRANCH_CCDB;
REC_PIPE.CLEARING_STATUS:=REC.CLEARING_STATUS;
REC_PIPE.FCL_CPTY_SK:=REC.FCL_CPTY_SK;
REC_PIPE.STRGRP:=REC.STRGRP;
REC_PIPE.OPEN_ENDED_FLAG:=REC.OPEN_ENDED_FLAG;
REC_PIPE.AVAILABILITY_IND:=REC.AVAILABILITY_IND;
REC_PIPE.ESCRW_FLG:=REC.ESCRW_FLG;
REC_PIPE.ESTABLISHED_RELP_FLG:=REC.ESTABLISHED_RELP_FLG;
REC_PIPE.GOV_GTY_AMT:=REC.GOV_GTY_AMT;
REC_PIPE.BUBA_CTRY_ID:=REC.BUBA_CTRY_ID;
REC_PIPE.GOV_GTY_CTRY_CD:=REC.GOV_GTY_CTRY_CD;
REC_PIPE.INTERNET_DPST_FLG:=REC.INTERNET_DPST_FLG;
REC_PIPE.LAST_ACTIVITY_DT:=REC.LAST_ACTIVITY_DT;
REC_PIPE.NOTICE_PERIOD_QTY:=REC.NOTICE_PERIOD_QTY;
REC_PIPE.OPR_RELP_FLG:=REC.OPR_RELP_FLG;
REC_PIPE.SIG_WD_PENALTY_FLG:=REC.SIG_WD_PENALTY_FLG;
REC_PIPE.TRN_ACT_FLG:=REC.TRN_ACT_FLG;
PIPE ROW(REC_PIPE);
END LOOP;
the Stored procedre returns REC_PIPE.
I thins this could be not efficient enough...
What do you think?

Convert Epoch Date Time to Date Time format

I am trying to convert Epoch Date time in GMT to Human Readable Date time format in UTC. I used the one below but it returns just the date in GMT but how can get datetime in UTC ?
select To_Char( To_Date( '01.01.1970 06:00:00','DD.MM.YYYY HH24:Mi:Ss') + STARTIME / 86400,'DD.MM.YYYY HH24:Mi:ss') FROM HQ_AVAIL_DATA_RLE;
I refered a couple of forums and applied everything, but still I wouldn't get the timestamp.
Please note that i'm looking for datetime stamp, not just the date.
Thanks in advance!
Edited by: 830754 on Jan 27, 2011 11:18 AM
Edited by: 830754 on Jan 27, 2011 11:19 AM

Works for me. I see date and time (submitted 1000 for STARTTIME):
select To_Char( To_Date( '01.01.1970 06:00:00','DD.MM.YYYY HH24:Mi:Ss') + 1000 / 86400,'DD.MM.YYYY HH24:Mi:ss')
from dual
TO_CHAR(TO_DATE('01
01.01.1970 06:16:40Or do you mean something else?

Pass a date parameter to Stored Procedure

Hello friends,
Can you help to pass a date parameter to Stored procedure from JSP. This is my code:
In Oracle 9i I have this:
PROCEDURE SP_EDORES(
pfechaini IN hist_pol_reclama.hrc_fecha_contabilidad%Type, <-- This is a date field
pfechafin IN hist_pol_reclama.hrc_fecha_contabilidad%Type, <-- This is a date field
p_recordset OUT PKG_REP_CIERRE.cursor_type) AS
In JSP have this:
CallableStatement stmt = (CallableStatement)conn.prepareCall( "begin PKG_REP_CIERRE.SP_EDORES(?,?,?); end;" );
stmt.registerOutParameter(3,oracle.jdbc.driver.OracleTypes.CURSOR);
stmt.setDate(1,Date.valueOf("01-06-2005"));
stmt.setDate(2,Date.valueOf("30-06-2005"));
ResultSet rset = (ResultSet)stmt.getObject(3);
while (rset.next()) {
%>
<TR>
<TD ALIGN=CENTER> <%= rset.getString(1) %> </TD>
<TD ALIGN=CENTER> <%= rset.getString(2) %> </TD>
<TD ALIGN=CENTER> <%= rset.getString(3) %> </TD>
<TD ALIGN=CENTER> <%= rset.getInt(4) %> </TD>
</TR>
<%
The Stored Procedure returns de Result set, however I think does not recognized the date format because I need it with this format dd-mm-yyyy.
Thanks in advance

to use Date you will need the oracle package.
u can try this other solution: use String, not Date
CallableStatement stmt = (CallableStatement)conn.prepareCall( "begin PKG_REP_CIERRE.SP_EDORES(?,?,?); end;" );
stmt.registerOutParameter(3,oracle.jdbc.driver.OracleTypes.CURSOR);
stmt.setString(1,"01-06-2005");
stmt.setString(2,"30-06-2005");
ResultSet rset = (ResultSet)stmt.getObject(3);
while (rset.next()) {
%>
if this don't work you can change your PL/SQL to get Strings and do the conversion with TO_DATE in the sql statement.

Use return date value in stored procedure

hi
i am new in oracle , i make stored procedure to fetch data in the form and i make calendar , i want user when they select a date from date LOV the stored procedure use this date in the query.. i try like this in the query:
when time=:blok.date_item;
but i get IN OUT error in the procedure.
any help will be appreciated.

ok this is the package header:
create or replace package get_outvalue_test is
type rec is record (time archive.time%type,
value archive%type);
type value_tab is table of rec index by binary_integer;
procedure get_value(p_returnvalue IN OUT value_tab);
end;
package body :
create or replace package body get_outvalue_test is
procedure get_value(p_returnvalue IN OUT value_tab)
is
ii number;
cursor valselect is
select time,value from archive where u_id=5666
and time=:block.date_item ; -- this is the return date from LOV
begin
open valselect;
ii:=1
loop
fetch valselect into
p_returnvalue(ii).time;
p_returnvalue(ii).value;
exite when valselect %notfound;
ii:=ii+1;
end loop;
end;
end;
this is the error when i compile the package body :
MIssing IN or OUT parameter at index
i hope itis cleare and easy .

Stored Procedure call from JDBC sender for Oracle Database

Hi,
I have a requirement to call stored procedure using JDBC sender adapter for retriving data from an Oracle database.
I need to execute first stored procedure call from Querry SQL statement and then trigger second stored procedure call for confirming the succesful retrival of those records from the update SQL statement.
Querries:
1. Can we trigger stored procedure from Update statement of JDBC sender.
2. Can we call stored procedure from Querry statement, since I have read on other sdn threads that stored procedure calls on Oracle database are not allowed. If not possible to have "Execute stored procedure" would the function call (select * from table(function name)) work same as stored procedure.
3. In a JDBC sender the Querry statement and Update statement are executed in same session call and same database connection. What happens if the querry statement was not succesful, would the update be still triggered.
Please note PI does not have direct access to main table and hence the need to have separate stored procedure calls.
The PI version is PI 7.11 sp4.
Appreciate your inputs.
Thanks.
Siddhesh S.Tawate

>1. Can we trigger stored procedure from Update statement of JDBC sender.
I think not possible using update statement.
> Can we call stored procedure from Querry statement, since I have read on other sdn threads that stored procedure calls on Oracle database are not allowed. If not possible to have "Execute stored procedure" would the function call (select * from table(function name)) work same as stored procedure.
Yes using select query you can call stored procedure.
>. In a JDBC sender the Querry statement and Update statement are executed in same session call and same database connection. What happens if the querry statement was not succesful, would the update be still triggered.
No select and update handles in the same session using the same thread so if one transaction fails update should not proceed.

Response from one stored proc. to another stored procedure call in JDBC

Hi,
I have to call 2 stored procedures, where the response from first stored procedure ( an id) is mapped as a parameter to the second stored procedure call.
My question is that can this be achieved without using BPM?
Can we somehow map the response from the stored procedure 1 to stored procedure 2 parameter w/o using BPM?
I have to insert multiple rows using the stored procedure.
Should I use STATEMENT unbounded times ( which means stored procedure is called multiple times) or should I use the parameter as unbounded ( like an array, maybe define the parameter as an array in the stored procedure)?
From the performance standpoint, which approach is better?
Please suggest.

Hi Ardent !
I think you could use 2 mapping programs (message mapping objects) in your interface mapping. The first one, executes and returns the ID to a message type defined by you for internal use only between both stored procedure executions. The second ones uses that message type as source message and the XML required by the JDBC for the second stored procedure execution as target message type. This can be done without BPM.
Regards,
Matias.

JDBC callableStatement stored procedure call cancellation?

up vote0down votefavorite
I have a very complex oracle stored procedure that searches and retrieves some data. The procedure returns an output parameter - an oracle cursor. I execute the procedure by JDBC:
CallableStatement stmt = conn.prepareCall("{call myprocedure(?,?,?,?}");
The problem is, the queries can sometimes take quite long (few minutes) and i would like user to be able to cancel the query anytime by clicking button. I have reference to stmt object, but unfortunatelly calling stmt.cancel() (from other thread) has NO EFFECT.
On the other hand when i change the CallableStatement sql to some query like:
CallableStatement stmt = conn.prepareCall("select * from all_objects");
i get "java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation" after calling stmt.cancel() - so thats the right reaction.
Does that mean than i cannot cancel stored procedure call via jdbc, but only simple select statements? Does anyone else had and resolved similar problem?
I guess i could cancel the query by oracle kill session, but i use connection pooling (jboss) and i have plenty of sessions for the same user existing.
Database Product Version is Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production JDBC Driver Version is 11.2.0.4.0
any help will be appreciated.

This property didnt help, still no reaction after statement.cancel().
I could not cancel the statment from the db size , so i decided to spawn new java thread and run the statement in that thread, and when user clicks cancel button i just cancel the thread, some snipper of code below:
               AtomicBoolean userCanceled - this must be AtomicBoolean or volatile variable, so other threads would see the change of variable after clicking button
               try{
                MyCallableQuery callable = new MyCallableQuery(rs,stmt,this,rsh,outParameter);
                FutureTask<T> queryTask = new FutureTask<T>(callable);
                ExecutorService executor = Executors.newFixedThreadPool(1);
                executor.execute(queryTask);
                while (!queryTask.isDone()){         //stil processing statement
                 Thread.sleep(100);
                      if (userCanceled)){               //user decided to cancel
                       futureTask1.cancel(true);
                       executor.shutdown();
                       throw new SQLException("User decided to cancel procedure call");
                 result = futureTask1.get();
                 //here the code after the resultset has been processed without cancelation
               catch (SQLException e}{
               //here the code when user decided to cancel like clearing the datatable
and my callable class is like:
public class MyCallable<T> extends ProcRunner implements Callable<T> {
    private ResultSet rs;
    private CallableStatement stmt;
    private ProcRunner procRunner;
    private ResultSetHandler<T> rsh;
    private Integer outParameter;
    public MyCallable(ResultSet rs,CallableStatement stmt,ProcRunner procRunner,ResultSetHandler<T> rsh,Integer outParameter){
        this.rs = rs;
        this.stmt = stmt;
        this.procRunner = procRunner;
        this.rsh = rsh;
        this.outParameter = outParameter;
    @Override
    public T call() throws Exception {
       T result = null;
      stmt.executeUpdate();
       rs = (ResultSet) stmt.getObject(outParameter);
       rs = this.wrap(rs);
       result = rsh.handle(rs);
    return result;

Date/Time Format Stored Procedure Calls in ADVANCE MODE in JDBC ADAPTER

Similar Messages

Maybe you are looking for