Scrollable cursors

Hello
I'm trying to explain why ansi style scrollable cursors are missing from Oracle to a group of people who are used to working with SQL server etc. Their position is that it's a pain in the backside to write a paging service into their application that will need to issue(taken from asktom)
select *
  from ( select a.*, rownum rnum
           from ( YOUR_QUERY_GOES_HERE -- including the order by ) a
          where rownum <= MAX_ROWS )
where rnum >= MIN_ROWSAs I understand, SQL server etc offer server side cached scrollable cursors but oracle does not. As I have seen so far, there is normally a very good reason why Oracle not to support a particular feature so in this case, does anyone know what it is?
Cheers
David

Andrew,
I've not been able to get a difinitive answer on whether JDBC supports the MS style scrollable cursors or not but from the discussion I had with a SQL server dba, he said that you could only specify the attributes of a cursor in TSQL. The more I thought about what our java guy was talking about and the inteded design of the system, the more I realised that he didn't really understand what he was asking. They are intending to use hibernate, which will generate SQL statements for basic crud operations and and wrap them in a set of java classes. They are not intending to use stored procs/ref cursors for anything so there is no way they could use the type of cursor he is on about (on SQL server or Oracle if it provided them)...or any declared type of cursor for that matter., they are just receiving result sets from straight sql statements.
3360
I have to agree with you whole heartedly. I've been on this contract for 5 weeks and so far I've produced one script to produce one table. The port is from a cobol system...The main idea is to treat the database as...you guessed it...a black box so that the application can be simply[i] put on any chosen database platform without batting an eyelid, and we retain all the "advantages" of platform independence.
Anyway, with very little else to do all day I'll continue to look for other work while keeping an eye on the forums and reading some very interestiong articles on ask tom. Sorry for the little rant, but I am going slowy insane ;-)
David

Similar Messages

  • Problem with scrollable cursors

    Hello,
    When I try to make a cursor scrollable by using SQLSetStmtAttr with parameters SQL_ATTR_CURSOR_SCROLLABLE and SQL_SCROLLABLE I get the error "[Oracle][ODBC]Optional feature not implemented".
    I have tried it with different types of cursors (Static, Keyset Driven, Dynamic). Isolation level is READ COMMITTED (default). I use ODBC Oracle Driver 11.1.
    What am I doing wrong?

    Can you pls check this link
    How do I get scrollable cursors with instant client unixODBC driver?

  • FOR UPDATE on scrollable cursor and error: ORA-00907: missing right parenthesis

    If change my query to have a FOR UPDATE and make it an updatable scrollable cursor I get an error on the updateRow() command saying "ORA-00907: missing right parenthesis"
    If I remove the FOR UPDATE it works OK.
    The problem I have is trying to update a CLOB from a ResultSet. If I do not upate any other column I get the error saying that the error"
    "ORA-22920: row containing the LOB value is not locked"
    I can get around this by adding FOR UPDATE. But if I add FOR UPDATE and try to update any non-CLOB column I get the 00907 error above.
    Hmmmm. So here is what I can and cannot do:
    - I CAN update the CLOB IF I update another column 1st and NO FOR UPDATE clause.
    - I CAN update the CLOB only if I have FOR UPDATE clause.
    - I CANNOT update just the CLOB without FOR UPDATE.
    - I CANNOT update any non-CLOB column with FOR UPDATE.
    What a pain in the ***! How am I to provide generic access to the applications being built on my DB layer. This is crazy!

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Andrew Edgar ([email protected]):
    I have this same problem!
    The error occurs when performing updateRow.
    The turning off of auto commit only gets the query to work but not the actual update.
    Will this be fixed in the next version of the Driver?<HR></BLOCKQUOTE>
    Here is the stack Trace I recieved:
    java.sql.SQLException: ORA-00907: missing right parenthesis
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
    at oracle.jdbc.driver.UpdatableResultSet.execute_updateRow(UpdatableResultSet.java:2135)
    at oracle.jdbc.driver.UpdatableResultSet.updateRow(UpdatableResultSet.java:1322)

  • Scrollable Cursor in Stored Procedure

    I am trying to implement a scrollable cursor that exists in a stored procedure. Here is my situation:
    o Oracle 9i (9.2.0.1.0) for both client and server.
    o OCI Interface in purely C++ environment
    o I am able to compile/link program with 9i client library, and successfully fetch data from a stored proc that contains a nonscrollable/forward only/traditional cursor without any problems.
    I have a stored proc that looks like this:
    procedure test(
    testcursor out cv_types.cv_fit_data
    ) as
    begin
    open testcursor
    for select data_id,
    text
    from data;
    end test;
    This is where I run into problems:
    First I allocate an OCIStmt handle and bind it to the proc. Then using the stmt handle that points to the proc, I bind a secondary handle that points to the cursor (testcursor above) by calling OCIBindByPos with type=SQLT_REF (See OCI ref manual on binding ref cursor). Next, I execute the proc via OCIStmtExecute with the mode=OCI_STMT_SCROLLABLE_READONLY using the statement handle that points to the procedure. Then I use that secondary stmt handle to fetch the rows via OCIStmtFetch2(). I am able to fetch the rows if I stick to OCI_FETCH_NEXT, but when I attempt to use any scrollable features such as OCI_FETCH_ABSOLUTE, it bails with an ORA-24391 error. Upon further investigation, I found out that this error occurs when the stmt is not executed with mode=OCI_STMT_SCROLLABLE_READONLY. The clincher is that I did execute in that mode... Has anyone been faced with a similar situation? Am I tackling this the wrong way? Any help, even pointers to any docs I missed on the subject, is greatly appreciated.
    Thanks,
    Bryan
    I am using OCI in C++ to fetch the data via OCIStmtFetch2(...) method.

    vaidyanathanraja wrote:
    4. If there is a logical error, the same procedure should not generate data when it is rerun. Behaviour should be the same at all times.Incorrect. Something like NLS settings for example can make the same code, behave differently. E.g. a date string is passed and implicitly converted to a date. And this will work for most dates from different session using different NLS settings (e.g. yyyy/mm/dd versus yyyy/dd/mm). And these sessions will provide different results using the same parameters calling the same application code.
    There are a number of such run-time factors that influences code.
    5. Failed means it didn't generate the expected output. Which means that there is a problem with that SQL being executed the way it is, with the parameters used. You need to isolate the problem further.
    6. Parameter values are right.Have you proved that by using a test case that runs the very same SQL via a test proc, using the same parameter, via a job? Ran that test case interactively via sqlplus?
    You need to pop the hood and isolate the problem.
    7. I came across one blog saying different behaviour for REF CURSOR between oracle 10g and 11g and he says it is oracle bug. I don't know whether it is applicable for this case also.Bahumbug. There are many Oracle bugs. As there is in all software. However, you have not provided any evidence of a bug.
    Application code is behaving inconsistently. That is the symptom. Oracle system code is not relevant until you can prove that the inconsistency is not in the application code, but lower down the call stack.

  • Scrollable Cursor lockup

    Hi,
    I'm using scrollable cursors to page a large result set. When two identical queries are issued in two separate threads, the application stops responding.
    On examining the code I find that the lockup occurs in the scrollable result set code, in particular, the ScrollableCursor::next(int number) method.
    Has anyone seen this, or have a suggestion on a different approach for solving this problem? Am I doing something obviously wrong? I've tried using the scrollable policy shown below, as well as the default one.
    I'm using classes12.zip.
    The code for the query is as follows:
              ReadAllQuery readAllQuery = readAllQueryForClass(targetClass);
              readAllQuery.setSelectionCriteria(whereExpression);
              readAllQuery.useScrollableCursor();
              ScrollableCursorPolicy scrollableCursorPolicy = (ScrollableCursorPolicy) readAllQuery.getContainerPolicy();
              scrollableCursorPolicy.setResultSetConcurrency(ScrollableCursorPolicy.CONCUR_READ_ONLY);
              scrollableCursorPolicy.setResultSetType(ScrollableCursorPolicy.TYPE_SCROLL_INSENSITIVE);
              readAllQuery.addOrdering(sortedByExpression);
              ScrollableCursor scrollableCursor =
                   (ScrollableCursor) this.acquireUnitOfWork().executeQuery(readAllQuery);
    The next is as follows:
    scrollableCursor.next(intValue);
    Thanks in advance
    - ted

    Look in the concepts for definition
    http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/sqlplsql.htm#sthref3449
    They are however supported currently only in OCI and recent JDBC afaik, not in PL SQL ( however can be simulated by means of collections).
    Best regards
    Maxim

  • Scrollable Cursor Vs Cursored Stream

    While working with streams in Toplink, are there any general guidelines? I mean the scenarios in which Cursored stream is beneficial and the scenarios in which Scrollable cursor is beneficial.
    From the outset it appears to me that Scrollable cursor is a better option, because i see that Cursored Stream always generates an additional count(*) query when i retrieve the total size of the cursor and because of this takes more time as compared to a Scroallable cursor.
    Thanks in advance for any information on this.

    The cursored stream must use a separate query to figure out its size. The scrollable cursor can simply scroll to the end and then scroll back. Scrolling to the end and then back is typically less efficient then a separate count(*) query.
    Doug

  • Oracle JDBC 8.1.6/Scrollable Cursor

    When using scrollable cursor on a table with varchar, getString() and getFloat() works but getObject() does not work. Why?

    Hi Ken,
    we have the same problem. getObject returns NULL on scrollable / updatable cursor while getString works. Using an ordinary statement (i.e. not JDBC2.0) both methods are working. We need the updatable cursor so if there will be no solution in time we have to switch back to an other database...
    Hopefully some one from Oracle will respond.
    Cheers.
    null

  • Scrollable cursors in oracle 8.1.7

    We are devloping application which is using VB as a front-end and SQL Server 2000 & Oracle 8.1.7 as back-end. I have created the procedure in SQL Server 2000 in which we have made an extensive use of scrollable cursors. But now i want to create such procedure in oracle 8.1.7, But i am not getting any help regarding scrollable cursors in oracle 8.1.7. So can anyone tell me is there any scrollable attribute defined in oracle 8.1.7 so that the previous or next record can be retreived.
    Thanks in Advance !

    For further reading:
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:1180618018840#3260280102622
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:127412348064#6969336986834
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:311216724461#31102007054659

  • Scrollable cursor

    whats the meaning of scrollable cursor when we use this cursor?

    Look in the concepts for definition
    http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/sqlplsql.htm#sthref3449
    They are however supported currently only in OCI and recent JDBC afaik, not in PL SQL ( however can be simulated by means of collections).
    Best regards
    Maxim

  • Scrollable cursor bug?

    Hello,
    When I first start my application from jdeveloper, I get this exception... Only once: when I do a "refresh", the application works normally and never gives the problem until the next server restart...
    500 Internal Server Error
    java.lang.NullPointerException     at java.lang.Class.forName0(Native Method)     at java.lang.Class.forName(Class.java:164)     at oracle.jdbc.driver.PhysicalConnection.safelyGetClassForName(PhysicalConnection.java:4583)     at oracle.jdbc.driver.PhysicalConnection.addClassMapEntry(PhysicalConnection.java:2737)     at oracle.jdbc.driver.PhysicalConnection.addDefaultClassMapEntriesTo(PhysicalConnection.java:2728)     at oracle.jdbc.driver.PhysicalConnection.initializeClassMap(PhysicalConnection.java:2456)     at oracle.jdbc.driver.PhysicalConnection.ensureClassMapExists(PhysicalConnection.java:2450)     at oracle.jdbc.driver.PhysicalConnection.getTypeMap(PhysicalConnection.java:2714)     at oracle.jdbc.driver.ScrollableResultSet.getObject(ScrollableResultSet.java:742)     at oracle.toplink.oraclespecific.Oracle9Platform.getObjectFromResultSet(Oracle9Platform.java:152)     at oracle.toplink.internal.databaseaccess.DatabaseAccessor.getObject(DatabaseAccessor.java:963)     at oracle.toplink.internal.databaseaccess.DatabaseAccessor.fetchRow(DatabaseAccessor.java:771)     at oracle.toplink.internal.databaseaccess.DatabaseAccessor.cursorRetrieveNextRow(DatabaseAccessor.java:352)     at oracle.toplink.queryframework.ScrollableCursor.retrieveNextObject(ScrollableCursor.java:512)     at oracle.toplink.queryframework.ScrollableCursor.loadNext(ScrollableCursor.java:357)     at oracle.toplink.queryframework.ScrollableCursor.hasNext(ScrollableCursor.java:233)     at be.uclouvain.doctorats.dao.factories.GenericFactory.searchAll(GenericFactory.java:198)     at be.uclouvain.doctorats.business.GenericBusiness.searchAll(GenericBusiness.java:188)     at be.uclouvain.doctorats.business.GenericBusiness.searchAllFromParent(GenericBusiness.java:393)     at be.uclouvain.doctorats.business.utils.Interlocutor.listObjects(Interlocutor.java:194)     at be.uclouvain.doctorats.action.ListAction.doAction(ListAction.java:55)     at be.uclouvain.doctorats.action.BasicAction.execute(BasicAction.java:46)     at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)     at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)     at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)     at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:711)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:117)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:110)     at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)     at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)     at java.lang.Thread.run(Thread.java:595)
    Here is the code that seems to cause the problem:
    ReadAllQuery readQuery = new ReadAllQuery(modelClass);
    List<ModelObject> toplinkResults = new ArrayList<ModelObject>();
    int chunkSize = 50;
    int index = 0;
    if (search != null) {
    readQuery.setSelectionCriteria(search.getExpression());
    chunkSize = search.getPageSize();
    index = search.getIndex();
    readQuery.useScrollableCursor(chunkSize);
    // lecture
    ScrollableCursor cursor = (ScrollableCursor)ToplinkFactory.getSession().executeQuery(readQuery);
    if (cursor == null) {
    throw new Exception("No cursor!");
    if (index > 0) {
    cursor.absolute(index);
    int size = cursor.size();
    int displaySize = chunkSize;
    // ajuster si page de données n'a pas sa taile max
    if (index + displaySize > size) {
    displaySize = size - index;
    for (int i=0; i < displaySize; i++) {
    if (!cursor.hasNext()) {
    throw new Exception("Cursor doesn't seem to work properly!");
    toplinkResults.add((ModelObject)cursor.next());
    I traced the problem to this line:
    if (!cursor.hasNext()) {
    It looks like a bug to me... Am I doing something wrong, or is it Toplink, or even jdbc???

    Ok, it seems to be only there when I run my
    application in debug mode in Jdeveloper... When
    running it regularly, it works correctly. Is it a
    jdev/oc4j bug, or is it a toplink bug which is
    triggered in some rare situation, or is it something
    else?Thats what you will have to debug further. :-)
    When you wrote "running it regularly" did you mean running it through JUnit?
    It could be the way you package/load classes in your JDeveloper environment. In order to eliminate the possibility of Toplink causing the bug you could write an identical test case in the app server except you can use JDBC ResultSet.

  • Possible Bug? SQL query changing the Cursor Type from Scrollable to non Scrollable in a ResultSet

    Hi all,
    I've been beating my head against this for a few days now, and while
    there is a workaround, I haven't found out what's causing this to
    happen.
    Every other SQL query except for this one particular query works fine
    and returns a scrollable result set. That one query on the other hand,
    returns a non-scrollable result set.
    Here's the code which is calling the query:
    sqlStatement = getSQLFromFile();
    debug("SQL statment = " + sqlStatement);
    stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
    debug(sqlStatement);
    rst = stmt.executeQuery(sqlStatement);
    debug("The type is " + rst.getType());
    rst.last();
    For most queries, the output is "The type is 1004" - which means the
    resultset is scrollable - as it should be.
    For one particular query, the output is "The type is 1003" which means
    that the result set is of type forward-only.
    Of course, calling rst.last() fails in the second case.
    If the difference between the queries was drastic, I might have
    something to go on. I've tested this out with different size queries,
    but the switch between having the type incorrectly changed is the
    deletion of a 0x0a 0x0d on the first line.
    I.E. this means the failing query reads :
    "select
    from........."
    and the query which works reads
    "select *
    from........."
    I've looked at the failing query in it's binary format, and that's the
    only difference I can discern.
    To further confuse things, there are other queries which have a
    similar format - and which work.
    I've read about a bug in Weblogic 5.1 SP9 which ignores the setting of
    the Statement to return a ResultSet with a scrollable cursor, and
    while this seems to be a bug, it doesn't seem the same bug at all -
    besides, I'm using Weblogic 6.0 with SP1 on a W2K system.
    Does anyone have any ideas as to what might be causing this? I'm
    stumped..

    Ryan D'Silva wrote:
    Hi Joe,
    I'm using the Oracle thin driver -
    oracle.jdbc.driver.OracleDriver - version #8.1.6.0.0
    and the DBMS is
    "Oracle9i Enterprise Edition Release 9.2.0.2.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.2.0 - Production"
    Does that help?Yes. Two things: TYou should probably upgrade the oracle thin
    driver, by downloading the latest appropriate one from their site,
    and make sure it's ahead of all weblogic jars in the classpath the
    server builds for itself. Also, let's see how simple we can make the
    problem. Would you please repeat the JDBC that demonstrated the problem,
    in a small standalone java program that uses a direct thin driver connection,
    getting weblogic out of the picture? (The problem does sound like
    and oracle driver issue).
    Joe
    >
    >
    Thanks,
    - ryan
    You don't say what DBMS and what JDBC driver you're using for the pool.
    That is likely to be the issue. Let me know.
    Joe
    Here's the code which is calling the query:
    sqlStatement = getSQLFromFile();
    debug("SQL statment = " + sqlStatement);
    stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
    debug(sqlStatement);
    rst = stmt.executeQuery(sqlStatement);
    debug("The type is " + rst.getType());
    rst.last();
    For most queries, the output is "The type is 1004" - which means the
    resultset is scrollable - as it should be.
    For one particular query, the output is "The type is 1003" which means
    that the result set is of type forward-only.
    Of course, calling rst.last() fails in the second case.
    If the difference between the queries was drastic, I might have
    something to go on. I've tested this out with different size queries,
    but the switch between having the type incorrectly changed is the
    deletion of a 0x0a 0x0d on the first line.
    I.E. this means the failing query reads :
    "select
    from........."
    and the query which works reads
    "select *
    from........."
    I've looked at the failing query in it's binary format, and that's the
    only difference I can discern.
    To further confuse things, there are other queries which have a
    similar format - and which work.
    I've read about a bug in Weblogic 5.1 SP9 which ignores the setting of
    the Statement to return a ResultSet with a scrollable cursor, and
    while this seems to be a bug, it doesn't seem the same bug at all -
    besides, I'm using Weblogic 6.0 with SP1 on a W2K system.
    Does anyone have any ideas as to what might be causing this? I'm
    stumped..

  • Need help with jdbc and cursor

    Hi all,
    I know I can specify a cursor to be scrollable with
    cs = conn.prepareCall("{call server.procedure(?,?)}",ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);
    but my problem is that this cursor is returning 2 oracle cursors and I need to move inside those but I cannot find the way to do it.
    cs.registerOutParameter(2, OracleTypes.CURSOR);
    rs = (ResultSet) cs.getObject(2); //this is the first cursor and is scrollable
    rs1= (ResultSet) rs.getObject(1); //this is one of the cursors inside the cursor and I cannot make it scrollable
    Thanks for the help,
    A.

    well, I didn't really check if the first one was scrollable since I didn't need it to be, but it seems that Oracle does not support scrollable cursors as out parameter of a stored procedure...
    anybody has a workaround?

  • Sensitive cursors

    Moved this post from the SQL PL/SQL forum. Apologies if you had to read this twice..
    All,
    I have a rather general question about oracle support for sensitive cursors, I need to establish a scrollable result set and "see" changes to the selected data, updated by a different process. There is some mention of oracle support for scrollable cursors that are sensitive, implemented in the JDBC driver.
    Is there something similar that I could use to enhance my OPEN cursor implementation in OCI.
    thanks in advance,
    badri

    A scrollable cursor provides support for forward and backward access into the result set from a given position, using either absolute or relative row number offsets into the result set.
    You can use scrollable cursor to see updated data if client side Caching is not used.
    Oracle does not support DML operations on scrollable cursors. A cursor cannot be made scrollable if the LONG datatype is part of the select list.
    Moreover, fetches from a scrollable statement handle are based on the snapshot at execution time. OCI client prefetching works with OCI scrollable cursors. The size of the client prefetch cache can be controlled by the existing OCI attributes OCI_ATTR_PREFETCH_ROWS and OCI_ATTR_PREFETCH_MEMORY.
    Example of Access on a Scrollable Cursor
    Assume that a result set is returned by the SQL query:
    SELECT empno, ename FROM emp
    and that the table EMP has 14 rows. One use of scrollable cursors is:
    /* execute the scrollable cursor in the scrollable mode */
    OCIStmtExecute(svchp, stmthp, errhp, (ub4)0, (ub4)0, (CONST OCISnapshot *)NULL,
    (OCISnapshot *) NULL, OCI_STMT_SCROLLABLE_READONLY );
    /* Fetches rows with absolute row numbers 6, 7, 8. After this call,
    OCI_ATTR_CURRENT_POSITION = 8, OCI_ATTR_ROW_COUNT = 8 */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 3,
    OCI_FETCH_ABSOLUTE, (sb4) 6, OCI_DEFAULT);
    /* Fetches rows with absolute row numbers 6, 7, 8. After this call,
    OCI_ATTR_CURRENT_POSITION = 8, OCI_ATTR_ROW_COUNT = 8 */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 3,
    OCI_FETCH_RELATIVE, (sb4) -2, OCI_DEFAULT);
    /* Fetches rows with absolute row numbers 14. After this call,
    OCI_ATTR_CURRENT_POSITION = 14, OCI_ATTR_ROW_COUNT = 14 */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 1,
    OCI_FETCH_LAST, (sb4) 0, OCI_DEFAULT);
    /* Fetches rows with absolute row number 1. After this call,
    OCI_ATTR_CURRENT_POSITION = 1, OCI_ATTR_ROW_COUNT = 14 */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 1,
    OCI_FETCH_FIRST, (sb4) 0, OCI_DEFAULT);
    /* Fetches rows with absolute row numbers 2, 3, 4. After this call,
    OCI_ATTR_CURRENT_POSITION = 4, OCI_ATTR_ROW_COUNT = 14 */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 3,
    OCI_FETCH_NEXT, (sb4) 0, OCI_DEFAULT);
    /* Fetches rows with absolute row numbers 3,4,5,6,7. After this call,
    OCI_ATTR_CURRENT_POSITION = 7, OCI_ATTR_ROW_COUNT = 14. It is assumed
    the user's define memory is allocated. */
    checkprint(errhp, OCIStmtFetch2(stmthp, errhp, (ub4) 5,
    OCI_FETCH_PRIOR, (sb4) 0, OCI_DEFAULT);
    checkprint (errhp, status)
    ub4 rows_fetched;
    /* This checks for any OCI errors before printing the results of the fetch call
    in the define buffers */
    checkerr (errhp, status);
    checkerr(errhp, OCIAttrGet((CONST void *) stmthp, OCI_HTYPE_STMT,
    (void *) &rows_fetched, (uint *) 0, OCI_ATTR_ROWS_FETCHED, errhp));
    ...

  • Cloudscape & scroll cursors

    I have created a database and table using the demo version of Cloudscape in WLS6.1.
    When I do a query and try to run the .first() method of ResultSet, I get an error
    that the operation is only allowed for "scroll cursors".
    How do I get around that ?

    You did not specify the language you want to implement this in and neither the Oracle version you are running.
    Scrollable Cursors were introduced begining with Oracle9i Release 2 in Pro*C/C++:
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c16sqlpl.htm#8111
    <quote>
    Scrollable Cursors
    Execution of a cursor puts the results of the query into a set of rows called the result set, which can be fetched sequentially or nonsequentially. Scrollable cursors are cursors in which fetches and DML operations do not need to be forward sequential only. Interfaces exist to fetch previously fetched rows, to fetch the nth row in the result set, and to fetch the nth row from the current position in the result set.
    See Also:
    Oracle Call Interface Programmer's Guide for more information about using scrollable cursors in OCI
    </quote>
    <quote>
    Scrollable cursors in Pro*C/C++ applications
    Scrollable cursors let you move forward and backward through the result set in a Pro*C/C++ application.
    </quote>
    http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a97269/pc_06sql.htm#8301
    http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a97269/pc_06sql.htm#8076

  • Need clarification CURSOR memory allocation

    Hi All,
    Pls help me to understand the below
    1. I declare a cursor when the memory is going to allocated for that ,Declaration or while Opening the cursor and from which memory it is going to allocate.
    2. If i close the cursor then memory is going to delocate or it is done later
    3.If i close a cursor and after that i am opening it again .. IS Memory is going to allocate again ..
    Thanks,
    Ravi

    > Pls help me to understand the below
    Before that, you need to understand what a cursor is.
    In a client language, a cursor is usually encapsulated in a class or variable - like the TQuery class in Delphi or the cursor variable in PL/SQL (e.g. cursor <var> is <sql select statement>). It needs a buffer area for fetched rows to be stored in. Some clients have cached and scrollable cursors, which means the client cursor will (attempt) to cache all the rows. Etc.
    Such a client language cursor construct resides in the data segment of the client program. In PL/SQL, this cursor variable/construct resides in the PGA.
    Client languages implements things like garbage collectors and so on - so we'll ignore the impact of these cursor constructs in the client language on memory.
    On the server-side, a cursor resides in the SQL engine (specifically in the Shared Pool in Oracle).
    Such a cursor consists of:
    - the source code program (i.e. the actual SQL statement)
    - the binary execution program (i.e. the execution plan containing the instructions on how to fetch the rows for the cursor)
    There is no such thing as a literal/physical cursor result set. The SQL engine does not allocate memory and store the result (e.g. rowid's) of the cursor in it.
    There is also a client cursor in the SQL engine. This can be thought of as a subclass of the cursor in the Shared Pool. This client cursor contains additional data such as the bind variable values you assigned to the cursor. The "data segment" of the binary execution program of the cursor. Etc.
    > 1. I declare a cursor when the memory is going to
    allocated for that ,Declaration or while Opening the
    cursor and from which memory it is going to
    allocate.
    The cursor's source code is parsed by the SQL engine and a binary program created on how to fetch the rows from the cursor. This resides in the Shared Pool. The size depends on the size of the source code, and the complexity/size of the binary program.
    When you use that cursor, the SQL engine creates a client cursor for you (which contains the bind values and so on).
    > 2. If i close the cursor then memory is going to
    delocate or it is done later
    On the server side, the cursor will remain in the Shared Pool. The client cursor will be released.
    The cursor in the Shared Pool will remain until aged out - in case someone else wants to use the same cursor/SQL program again.
    > 3.If i close a cursor and after that i am opening it
    again .. IS Memory is going to allocate again ..
    Oracle receives your SQL. It checks in the Shared Pool for an existing cursor that contains the same source code. If one is found, that cursor's binary program can be used (called a soft parse and is inexpensive) - no need to parse and recompile your SQL into a brand new cursor (called a hard parse which is very expensive).
    Again, a client cursor in the SQL engine is created - which will contain your bind variables and so on.

Maybe you are looking for