I am new to r2dbc, our case is reading a ref cursor returned by an Oracle stored procedure. As described here https://github.com/oracle/oracle-r2dbc/blob/main/README.md, this can be done like this:
Publisher<Result> executeProcedure(Connection connection) {
connection.createStatement("BEGIN example_procedure(:cursor_parameter); END;")
.bind("cursor_parameter", Parameters.out(OracleR2dbcTypes.REF_CURSOR))
.execute()
}
However, it seems the OracleR2dbcTypes.REF_CURSOR constant (and the ref cursor support in general) is not released yet. It is not available in version 1.0.0 (the last one). It was introduced with the following commit:
Michael-A-McMahon committed on Sep 15
1 parent e8fc172 commit c4f7e2be06aa9083451f4c6b67162c2ae460c0b2
My question is: when is the ref cursor support planned to be released? Until then, is it possible somehow to bind the cursor, and read it from the result?
Related
Oracle's SQL Developer doesn't display the content of XML columns when the datatype XMLType is used. The first lines are displayed ok (if Preferences > Database > Advanced > Display XML Value in Grid is ticked), but once you doubleclick on the little yellow pencil, the "View Value" window remains empty. Curiously, it works if you store the XML in a clob.
CREATE TABLE t (x XMLTYPE, c CLOB);
INSERT INTO t VALUES (XMLTYPE('<x/>'), '<x/>');
COMMIT;
SELECT * FROM t;
After a lot of internet search, I found a post by thatJeffSmith saying that it's a known bug and will be fixed soon. And yes, it is working again from version 19.1 onwards. However, at work we are stuck with version 18.2 for a while. So, is there a workaround in 18?
Version XML View Value
17.3.0.271 ok
17.4.0.355 ok
18.1.0.095 empty
18.2.0.183 empty
19.1.0.094 ok
19.2.1.247 ok
19.4.0.354 ok (but needs modern JDK)
This is how it looks in 19.1:
Secondly, I couldn't find a list of bugs for SQL Developer, or a list of fixed bugs, or old release notes. Currently, Oracle's download page lists only the latest three releases 19.1, 19.2 and 19.4, so it's impossilbe to find out when this bug was fixed.
The proper solution is an upgrade to version 19 (or theoretically downgrade to 17).
If you are stuck in Version 18, there is a workaround:
SELECT t.x.getClobVal() FROM t t;
For some strange reason, the table alias is required.
We have recently uplifted a major application that was written under JDK6 using ojdbc6 against an 11g Oracle database. It was uplifted to use JDK8 against the same 11g database, but we were also in the midst of upgrading to 12c. The uplifted code has been running in production against the 11g database, but slower than it was before. Against the 12c database in our QA environment, we're noticing jobs either throwing exceptions or running VERY slow. When I looked at the code, I noticed that the project team assigned to uplift the code failed to upgrade the ojdbc from 6 to at least 8. I have since done that work, but now we are getting errors from submitting the following code:
Calendar endModDate = Calendar.getInstance();
// get the timestamp from the db
Query qry = em.createNativeQuery("select SYSTIMESTAMP from dual");
TIMESTAMPTZWrapper tsTZWrapper = (TIMESTAMPTZWrapper)qry.getSingleResult();
The em is our entity manager. But when the code calls the qry.getSingleResult() member function, we get this error:
oracle.sql.TIMESTAMPTZ cannot be cast to org.eclipse.persistence.internal.platform.database.oracle.TIMESTAMPTZWrapper
I've searched high and low for an answer, and anything that resembles an answer doesn't appear to fix my solution. This same logic is used in one other area of the code and produces the same issue. If we switch back to ojdbc6, it then works but we can't use ojdbc6 (and we really shouldn't since we're on jdk8) since we need to upgrade to Oracle 12c in the coming month.
Thanks for any assistance in this matter.
Just quick comment about TIMESTAMP datatype:
There is a bug in JDBC drivers "Bug 21891493 : JDBC SENDS TIMESTAMP SCALE OF NULL WHEN NANOSECONDS ARE ZERO", which can cause creation of excessive number child cursors in Oracle database. This bug was fixed in 12.2 JDBC drivers.
The datatype TIMESTAMP WITH TIMEZONE uses internally a function to convert the this into GMT. When you create an index on it, in some cases this function based index is not used, especially when you compare this column with TIMESTAMP value of different subtype. You should compare exec plans between 11g and 12c.
I'm trying to get SAP Business Objects to get a report off of a stored procedure. I had no luck, so I'm now just trying with an example/tutorial of how to do it I found online, and I can't get that to work either.
I'm following:
https://irfansworld.wordpress.com/2012/11/17/what-you-should-know-about-stored-procedure-universe-in-bi-4-0/
I created the objects shown in the exact same way, as shown here:
create or replace package emp_package
as type emp_row_type is ref cursor return emp%rowtype;
end emp_package;
/
create or replace
procedure getEmployeesByDepartment
(
return_rows_cursor in out emp_package.emp_row_type,
dept_parameter in emp.deptno%type
)
as begin
open return_rows_cursor for
SELECT *
FROM emp
WHERE emp.deptno = dept_parameter;
end;
/
I get good results back:
Package EMP_PACKAGE compiled
Procedure GETEMPLOYEESBYDEPARTMENT compiled
But here is where I see a glaring difference... For me, it takes what should only be the out/return parameters, and prompts me as if they are input parameters.
Even if i say "OK" to this... it doesn't recognize the fields in the "out" cursor as fields for me to show on the report.
I've even tried changing the cursor paramater from "in out" to just "out"... but still no luck.
Any ideas as to why I can't make this example work for me?
Using SAP Universal Design Tool 4.1.
Oracle 11g
This isn't really an answer, but too long for a comment.
I just tried this with BI4.1 SP Patch 5, and the SP Editor displayed as expected (only showing the DEPT_PARAMETER parameter).
Two possibilities I can think of for the different behavior you're seeing:
One is that there's something going on with the database middleware client that's confusing BO about the parameters. I'm using Oracle 11g client, and an Oracle Native connection in BO (i.e., not ODBC or JDBC). If you're using an ODBC or JDBC connection, try the native client instead.
It might be a bug with the specific version of UDT that you're using. I'd suggest upgrading, or contacting SAP support to see if it's a known issue.
in our work we create two .net listener,
first one:
calling oracle stored procedure that insert bulk of data into table(table1) using insert into select syntax:
insert into table1 select c1,c2... from tbl2 inner join tbl3....
then we use explicity commit;
second listener:
calling oracle procedure that reading data inserted into table1 via listener1
but we notice that even the record inserted into table1 listener2 couldn't see that recordat same time even that commit is use.
my question is how does cmmit work when we use insert ...select?
is this issue related to session?when listener 1 session end listener 2 can read data?
please help,
thank in advance.
You're using the wrong terms...
A listener is a server application that listens to the incoming client requests and hands it to the DB engine. A listener is not being used on the client end.
A session is not related to the data you can see, a transaction is the object that controls that.
Oracle works in a very clear way - After a transaction has committed - all the new transactions can see it, and already existing transactions can see the new content based on it transaction configurations..
I recommend you reading about isolation levels in that context http://msdn.microsoft.com/en-us/library/system.transactions.isolationlevel(v=vs.110).aspx
By default - the moment (and in DB it is defined by SCN) a transaction have been committed - the data is visible to the client.
Bottom line - your issue is related either to transaction isolation levels (in the case the reading transaction started before the commit), or to the writer, which does not commit the data when you think it is (a transaction issue).
After the call to transaction.Commit() in .net returned - the data is already visible, and other transactions are seeing it.
You're second question was how commit works.
This is a very complicated process in Oracle, so I'll give a really short description:
1. When you commit, Oracle first runs some verifications before the commit itself (for example, runs the deferred constraints).
2. After oracle knows it can safely commit the changes it gets the system time (SCN) , write the commit itself to the redo log, and flushes the data to disk (for consistency).
3. Sends an ACK to the user, that the data is already visible to the world.
4. marks the buffers been used as free.
Something I want to add, just to make sure (and I'm writing it half a sleep - so excuse me if it does not compile...)
In you're .net code - your code should be logically equivalent to it:
OracleConnection con = new OracleConnection(connStr);
con.Open();
OracleTransaction trans = con.BeginTransaction();
OracleCommand cmd = con.CreateCommand();
cmd.Connection = cmd;
cmd.CommandText = "insert into ...";
cmd.ExecuteNonQuery();
cmd.Dispose();
trans.Commit();
trans.Dispose();
con.Close();
con.Dispose();
and if you're using LINQ - make sure you create the transaction scope on the right area.
If I use DBMS_OUTPUT.PUT_LINE() method, it always appends a new line character at end.
But what if I want to print lets say Fibonacci series in same line.
I know the logic of fibonacci...
I just want to know which method would I use to put whole output in same line.
I am using PL/SQL
Use DBMS_OUTPUT.PUT instead of DBMS_OUTPUT.PUT_LINE
The entry point for all the doc of version 11gR2 is All Books for Oracle Database Online Documentation Library 11g Release 2 (11.2).
For other Oracle database versions you might want to start your exploration from Database Documentation. Since version 12.1 the URLs are easier : http://docs.oracle.com/database/121/nav/portal_booklist.htm for 12.1 and http://docs.oracle.com/database/122/nav/portal_booklist.htm for 12.2.
You might want to check PL/SQL Packages and Types Reference for that kind of question. In particular the Summary of DBMS_OUTPUT Subprograms. The doc is really handy as a reference when you have questions about the PL/SQL API.