About for update clause

hi, i want to lock some rows that i've selected in a program. so, i use a for update clause. Here is my query:
SELECT *
FROM (
     SELECT name, age, classe, average
     FROM student
     WHERE average >= '15'
     AND warning is NULL
     AND status = '1'
     ORDER BY age
     FOR UPDATE OF average)
WHERE ROWNUM <= 5
the problem is that the oracle server always return this message:
ORA-00907: Parenthèse de droite absente
May you tell me what's wrong with this query? according to the Oracle message, it seems that i don't close a bracket,but it is not the case.So what it is the problem?
thanks.

It seems that you cannot have a FOR UPDATE clause in a inline view and that you cannot use the FOR UPDATE clause for an inlinve view if the inline view has an ORDER BY clause.
One solution is to create a temporary table to store the rowids of the table your want to select for update.
Example:
create global temporary table student5
( orowid rowid )
on commit preserve rows;
insert into student5
select rowid
from (select rowid
from student
where average >= 15
and warning is null
and status = '1'
order by age)
where rownum <= 5;
select * from student where rowid in (select orowid from student5) for update;Note also that if student.average column is numeric, you should not use quotes for '15'.

Similar Messages

  • Pros and  cons  of  select  for  update  clause

    hi,
    Can anybody explain what are the
    pros and cons of select for update clause
    11.2.0.1

    As commented, there are no pros versus cons in this case.
    What is important is to understand conceptually what this do and why it would be use.
    Conceptually, a select for update reads and locks row(s). It is known as pessimistic locking.
    Why would you want to do that? Well, you have a fat client (Delphi for example) and multiple users. When userA updates an invoice, you want that invoice row(s) locked and prevent others from making updates at the same time. Without locking, multiple users updating the same invoice will result in existing updated data being overwritten by old data that also has been updated. A situation called lost updates.
    For web based clients that are stateless, pessimistic locking does not work - as the clients do not have state and pessimistic locking requires state. Which means an alternative method to select for update needs to be used to prevent lost updates. This method is called optimistic locking.
    So it is not about pros versus cons. It is about understanding how the feature/technique/approach works and when to use it.. and when it is not suited to use it. All problems are not nails. All solutions are not the large hammer for driving in nails.

  • ERROR using SQL Server 2000, FOR UPDATE clause problem

    Hi All,
    Because our main target for RDBMS mostly SqlServer2000, I try to use ADF BC with one. I successfully run the BC with Tester, scrolling up and down, BUT when i try to make changes and do commit, I receive ERROR, I have tried both JDBC Driver from Microsoft and jTDS, both FAILS.
    I have set the 'Default Locking Mode ..' to 'optimistic'
    (default is 'pessimistic'), it doesn't help.
    Here is the error :
    With Microsoft JDBC Driver :
    (oracle.jbo.DMLException) JBO-26080: Error while selecting entity for Departments
    ----- LEVEL 1: DETAIL 0 -----
    (java.sql.SQLException) [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer] FOR UPDATE cannot be specified on a READ ONLY cursor.
    With jTDS JDBC Driver :
    (oracle.jbo.DMLException) JBO-26080: Error while selecting entity for Departments
    ----- LEVEL 1: DETAIL 0 -----
    (java.sql.SQLException) Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR.
    Pls any body help...
    Thank you,
    Krist

    Krist,
    we added a new SQL Flavor 'SQLServer' in JDeveloper 10.1.2
    This was implemented to handle special SQL syntax of SQLServer, different from SQL92 (among others the FOR UPDATE problem you're facing).
    For new projects, you can select this flavor during their creation. For projects that were defined with Flavor SQL92, you can switch to SQLServer at runtime by setting the parameter jbo.SQLBuilder=SQLServer (in your Application Module configuration or as a java option -Djbo.SQLBuilder=...)
    Regards,
    Didier.

  • How to avoid 'for update' clause ?

    Hi All,
    I am trying to build the data-entry form based on complex view. I've got JBO-26080 Error while selecting entity...
    (ORA-02014 select ... for update).
    Is it possible to delete 'for update' clause in select ?
    What is the best practice to deal with data-entry form for many View Objects ?

    I believe the "for update" is issued because of your locking mode. (It's probably jbo.lock.mode in the app-module configuration?)
    If lock-mode is pessimistic then a for-update should be issued right away; if it's optimistic it'll be issued as part of the commit process (the lock isn't held for very long!); it it's "none" it won't be issued at all.
    HTH
    Mike.

  • How to unlock a row if i use FOR UPDATE clause

    In procedure if we use FOR UPDATE clause, it will lock particular row and allow only one client to update whereas other client can only fetch data in the same row at that time.
    My question is when will it unlock the row, what should we do to unlock the row while writing procedure. Take this example here im using FOR UPDATE clause for client_count, when ll it unlock that particular row in this procedure.
    create or replace PROCEDURE newprocedur(inMerid IN VARCHAR2,outCount OUT NUMBER) AS
    CURSOR c1 IS
    select CLIENT_COUNT from OP_TMER_CONF_PARENT where MER_ID = inMerid FOR UPDATE OF CLIENT_COUNT;
    BEGIN
    Open c1;
    loop
    fetch c1 into outCount;
    exit when c1%NOTFOUND;
    outCount:=outCount+1;
    update OP_TMER_CONF_PARENT set CLIENT_COUNT = outCount where current of c1;
    end loop;
    close c1;
    END;

    Hi,
    Basically you are incrementing client_count by 1 , Why you have to fetch row one by one and update? you could just finish that in a single update
    UPDATE OP_TMER_CONF_PARENT
    SET CLIENT_COUNT = CLIENT_COUNT+1
    WHERE MER_ID     = inMerid This will increment client_count of all rows by one for the given mer_id;
    After updating you have to make the changes permanent so that other users will see the changes you have made.
    To lock the row before update you can use same select statement in you cursor
    SELECT CLIENT_COUNT
    FROM OP_TMER_CONF_PARENT
    WHERE MER_ID = inMerid FOR UPDATE OF CLIENT_COUNT;You can further modify the procedure to let other users know if the row is being updated.
    Regards
    Yoonas

  • RE: for update clause

    Hi,
    If you are using Forte as 2-tier tools, there shouldn't be any problem in
    using select ... for update. The sql is actually passed through to your
    back-end database. So everything should work the same, provided that every
    user has his own database session ( like by using DBResourceMgr to create
    DBSession at run-time for each user. )
    However, if you are building multi-tier application, there is no simple
    answer to your question. The problem is common to all 3-tier application
    since the application / database layer is shared among many users. If you
    start a transaction from client side, use select ... for update to lock a
    record, allow user to change data, then update and end the transaction, you
    are not just locking up a record, but also a database session. In such
    model, you will run out of DBSession very soon.
    What we did here is to use a "lock count", which exists is every table.
    When client retrieves a record, it won't start a transaction there. A
    transaction is started only on the server and after client commits its
    changes to the server. Data consistency is checked by checking the lock
    count in the update where clause.
    It looks dumb, but it's the only solution that we can reach after consulting
    a lot of white paper and Forte consultants. Moreover, Forte consultant also
    said its bad to start a transaction on client side.
    I do hope that there is a better solution out there in handling 3-tier
    applications too. Afterall, this lock count thing is clumsy.
    Peter Sham.
    -----Original Message-----
    From: Phong Tran [SMTP:[email protected]]
    Sent: Thursday, March 18, 1999 6:50 AM
    To: [email protected]
    Subject: for update clause
    dear forte-users,
    I notice the "for update" clause can only used with cursor.
    Just wonder why you can not use it with "sql select ...." statement.
    Also as I understand it, one way to protect the data consistency is
    through
    the mutex lock but then you turn the object to a single-threaded to
    serialize access even though you access different rows in a
    database
    table. The fact is you only want access on a particular row.
    Does anyone know the best way to lock a row (or rows) in the
    database ?
    If you have to rely on the "for update" clause in the cursor
    definition for
    the locking, then you almost end up with a lot of cursors.
    Example: the method ReadnWriteDB(ordeId) accesses a specific row
    but since the orderOBj serializes access, other tasks have to wait.
    OrderObj: OrderMgr = new(IsShared = TRUE, IsTransactional = TRUE);
    method GetOrderInfo() of the TransactionSO.
    begin transaction
    OrderObj.ReadnWriteDB(orderId);
    end transaction;
    From Client:
    Begin
    start task TransactionSO.GetOrderInfo(orderId);
    end;
    Phong
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive
    <URL:http://pinehurst.sageit.com/listarchive/>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    Which application front end are you using.
    Also, you'll get the same error if your Query runs too long, and/or your rollbacks are too small.

  • Using for update clause in VPD(Virtual Private Databases)

    Hi,
    We are using for update clause in our procedure to explicitly lock rows in a particular table as shown below:
    SELECT AMOUNT FROM INTERFACE_TABLE
    INTO T_Amount
    WHERE ROWID = :B1
    FOR UPDATE OF BANK_ACCOUNT_NUM NOWAIT;
    But this statement is giving the following error in VPD:
    ORACLE error 1733 in FDPSTP
    Cause: FDPSTP failed due to ORA-01733: virtual column not allowed here.
    We need to lock rows in that particular table until the commit is issued,so as to prevent the updation of the rows which are being processed.
    Is there any other way in which this can be achieved.
    Thanks & Regards,
    Brahmendra Kashyap

    From the docs, which you didn't read:
    ORA-01733 virtual column not allowed here
    Cause: An attempt was made to use an INSERT, UPDATE, or DELETE statement on an expression in a view.
    Action: INSERT, UPDATE, or DELETE data in the base tables, instead of the view.
    Can you explain why you didn't read the docs? I'm just curious why so many people do absolutely nothing to resolve their problem (they would learn Oracle by doing so) and request to be spoon fed.
    Sybrand Bakker
    Senior Oracle DBA
    Experts: those who did read the documentation.

  • Cursor with for update clause problem

    Hi all,
    We are having this problem with Oracle 8.1.7 where in we have a cursor with for update clause. The PL/SQL script used to work fine with Oracle 8.0.5 but is causing problems with Oracle 8.1.7. What the script is ending up doing in 8.1.7 is that it updates only one record instead of updating close to 60000 which it used to do in Oracle 8.0.5
    The script just hangs after updating one record. We have replicated the same problem.
    Has anyone seen this error before and attained resolution?
    Thanks

    Hello ,
    I have found the same / very close to the same problem. I tried the code below in Oracle 10.2.0.1 and got the following error after the first loop.
    ORA-01002: fetch out of sequence
    ORA-06512: at "DEMO_TEST_RESEARCH_PKG", line 18
    ORA-06512: at line 7
    After trying to debug it , i thought i would try it in Oracle 9.0.2.0.7.0 , and to my suprise it worked fine.
    Am i missing something ? Thanks in advance , ...
    I have included the code i was running ...
    PROCEDURE WhereCurrentOf(Param1 IN NUMBER) IS
    v_title_eng ISSUES.TITLE_ENG%TYPE;
    v_issue_id ISSUES.ISSUE_ID%TYPE;
    CURSOR issues_cur
    IS
    SELECT issue_id,title_eng
    FROM issues
    WHERE title_eng IS NULL
    FOR UPDATE OF title_eng;
    BEGIN
    FOR i IN issues_cur
    LOOP
    FETCH issues_cur INTO v_issue_id,v_title_eng;
    EXIT WHEN issues_cur%NOTFOUND;
    DBMS_OUTPUT.PUT_LINE(v_issue_id||' This was the english title before : '||v_title_eng);
    v_title_eng := 'This is my title';
    UPDATE issues
    SET title_eng = v_title_eng
    WHERE CURRENT OF issues_cur;
    DBMS_OUTPUT.PUT_LINE(v_issue_id||' This is the english title after : '||v_title_eng);
    END LOOP;
    END WhereCurrentOf;

  • For update clause

    Hi all
    in cursor with select for update clause we can reference column list. like
    select.......
    from....
    for update [of column_reference]
    I want to know that what is the use of specifying column nane in for update clause?
    because its main purpose is to lock rows before update or delete, and complete row will be locked not only that column, then what is the use of mentioning it.
    Secondly, I want to know that when we perform dml then automatically locks occur, then why we use for update clause.???
    third,
    when locks occur, when we open cursor or when update or delete???

    If you've got FireFox, you can add tahiti.oracle.com and asktom.oracle.com to the list of search engines you have available in the upper right-hand corner. I can't tell you how addicted I am to that little piece of heaven.
    Justin

  • Form4.5 For update clause in cursor problem

    Hi,
    I am putting this code in my forms4.5 pl/sql block and get the error when compile the pl/sql block.
    "Encountered ";" when expecting "of".....
    Code is:
    Select null INTO dummy from mytable
    where id = 1456
    for update nowait;
    If I remove for update clause it compiles ok.
    So can anyone tell me what's going on here...
    thx

    Actually I used...
    For update of column_name and it worked.
    I have another problem which I am posting here in a new thread.
    thx

  • How to alter the materialized view defintion with -- For update clause

    My db version is 9.2.0.3
    My orginal materialized view difination does not have "for update " clause.
    how can i alter the mview defination to inclused and exclude the "for update" clause.
    I dont want to drop and recreate the mview with for update clause. But I what to change the existing definition.
    Please suggest.
    Thanks
    Naveen.

    I already have the view definition in place. I want to change the exising defination, by adding the "for update " clause. Is it possible with any " alter mview ... " syntax.
    Below is my existing syntax. I don't what to drop and recreate. Just want to alter the existing definition , with for update clause.
    create materialized view test
    pctfree 0
    tablespace DATA storage (pctincrease 0)
    build immediate refresh start with sysdate next (trunc(sysdate+1) +1/24)
    with primary key
    disable query rewrite
    as select * from test@isource;
    Please suggest!
    Thanks
    Naveen
    Edited by: user12096071 on Apr 8, 2010 2:56 PM

  • ADF and MSSQL 2005 problems - FOR UPDATE clause allowed only for DECLARE C

    Hi all.
    I have a legacy application which uses MS SQL server 2000 / 2005. I've started to build up a new version of this application using JDev + ADF stack.
    Everything went ok until I've tried to update some data in a Form. I'm getting this error:
    com.microsoft.sqlserver.jdbc.SQLServerException: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR
    Can someone figure out what's wrong?
    1) In a MSSQL server connection string, normally we define the 'SelectMethod' parameter to 'cursor', as follows: jdbc:sqlserver://$host$:$port$;databaseName=dbserver;SelectMethod=cursor
    Since I was not able to do this through my project's 'Application Resources > Connections' screen, I could not evaluate if this is the cause
    2) I'm trying to follow the steps of an Oracle tutorial (http://www.oracle.com/technology/obe/obe11jdev/ps1/ria_application/developriaapplication_long.htm#ad), of course using MS SQL server instead of Oracle, and using some master->detail tables like the example suggests (in the tutorial, I've reached the step 11, then tried to update a record, which causes the mentioned exception)
    Follows the stacktrace:
    <Utils><buildFacesMessage> ADF: Adding the following JSF error message: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR.
    com.microsoft.sqlserver.jdbc.SQLServerException: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR.
         at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
         at com.microsoft.sqlserver.jdbc.IOBuffer.processPackets(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerStatement.getMoreResults(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerStatement.seekToOutParams(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.getPrepStmtHandle(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doPrepExec(Unknown Source)
         at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(Unknown Source)
         at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelectForAltKey(BaseSQLBuilderImpl.java:707)
         at oracle.jbo.server.BaseSQLBuilderImpl.doEntitySelect(BaseSQLBuilderImpl.java:546)
         at oracle.jbo.server.EntityImpl.doSelect(EntityImpl.java:7789)
    Regards,
    Luciano S. Lorencini, SCJP, SCWCD

    So, I`ve created a test project and use the MSSQL flavor to create my Business Components.
    After repeated all the steps, the error did not happen again.
    But some strange behavior happen: I change some data and click the "Submit" button. The changed data appears ok in screen, but the changes were not committed in database!
    Do I need to explicitly tell ADF to commit that changes somewhere?
    Greetings,
    Luciano S. Lorencini, SCJP, SCWCD

  • System.prefs -- FOR UPDATE clause

    When moving to a new mysql database, it gave me the error that it
    doesn't suppport the "FOR UPDATE" clause. Turns out the database was an
    older one. I tried to add the
         <mysql>
              <select-for-update>false</select-for-update>
         </mysql>
    section to system.prefs, but no matter where I put it, it had no effect.
    The documentation wasn't exactly clear where it goes. Now, I'm not
    using the default database -- I'm specifying a named database. I'm
    guessing that this option isn't working with named databases in the
    systems.prefs file. Could you clarify this?
    Thanks,
    Dan

    Worked like a champ! Thanks again, Patrick.
    Dan
    Patrick Linskey wrote:
    On 6/6/02 3:56 AM, "Dan Finkelstein" <[email protected]> wrote:
    When moving to a new mysql database, it gave me the error that it
    doesn't suppport the "FOR UPDATE" clause. Turns out the database was an
    older one. I tried to add the
    <mysql>
    <select-for-update>false</select-for-update>
    </mysql>
    section to system.prefs, but no matter where I put it, it had no effect.
    The documentation wasn't exactly clear where it goes. Now, I'm not
    using the default database -- I'm specifying a named database. I'm
    guessing that this option isn't working with named databases in the
    systems.prefs file. Could you clarify this?
    If you're using a named db, you should do
    <db>
    <your name here>
    <select-for-update>false</select-for-update>
    </your name here>
    </db>
    Note that turning off select for update is bad, because it essentially
    defeats pessimistic locking, and you probably shouldn't ever see an error if
    you aren't using pessimistic locking. So, I'd recommend that you use
    optimistic locking with old MySQL installs instead.
    Thanks,
    Dan

  • Cursor have for update clause

    Hi all,
    Can any one please tell me,what is main use of for update cursor.in which case we are using this clause.with simple example can any one please explain.
    Thanks,
    K.venkata Sanjeeva Rao.

    user13483989 wrote:
    Can any one please tell me,what is main use of for update cursor.in which case we are using this clause.with simple example can any one please explain.Where you are looping through data for some reason and want to update the current row.
    Simple example...
    SQL> select * from emp;
         EMPNO ENAME      JOB              MGR HIREDATE                    SAL       COMM     DEPTNO
          7369 SMITH      CLERK           7902 17-DEC-1980 00:00:00        800                    20
          7499 ALLEN      SALESMAN        7698 20-FEB-1981 00:00:00       1600        300         30
          7521 WARD       SALESMAN        7698 22-FEB-1981 00:00:00       1250        500         30
          7566 JONES      MANAGER         7839 02-APR-1981 00:00:00       2975                    20
          7654 MARTIN     SALESMAN        7698 28-SEP-1981 00:00:00       1250       1400         30
          7698 BLAKE      MANAGER         7839 01-MAY-1981 00:00:00       2850                    30
          7782 CLARK      MANAGER         7839 09-JUN-1981 00:00:00       2450                    10
          7788 SCOTT      ANALYST         7566 19-APR-1987 00:00:00       3000                    20
          7839 KING       PRESIDENT            17-NOV-1981 00:00:00       5000                    10
          7844 TURNER     SALESMAN        7698 08-SEP-1981 00:00:00       1500          0         30
          7876 ADAMS      CLERK           7788 23-MAY-1987 00:00:00       1100                    20
          7900 JAMES      CLERK           7698 03-DEC-1981 00:00:00        950                    30
          7902 FORD       ANALYST         7566 03-DEC-1981 00:00:00       3000                    20
          7934 MILLER     CLERK           7782 23-JAN-1982 00:00:00       1300                    10
    14 rows selected.
    SQL> ed
    Wrote file afiedt.buf
      1  declare
      2    cursor cur_emp is
      3      select empno, ename, comm
      4      from emp
      5      for update;
      6  begin
      7    for e in cur_emp
      8    loop
      9      dbms_output.put_line('('||e.empno||') '||e.ename);
    10      if e.comm is null then
    11        update emp
    12        set comm = 0
    13        where current of cur_emp;
    14        dbms_output.put_line('-- Commission reset to 0');
    15      else
    16        dbms_output.put_line('-- Commission: '||e.comm);
    17      end if;
    18    end loop;
    19* end;
    SQL> /
    (7369) SMITH
    -- Commission reset to 0
    (7499) ALLEN
    -- Commission: 300
    (7521) WARD
    -- Commission: 500
    (7566) JONES
    -- Commission reset to 0
    (7654) MARTIN
    -- Commission: 1400
    (7698) BLAKE
    -- Commission reset to 0
    (7782) CLARK
    -- Commission reset to 0
    (7788) SCOTT
    -- Commission reset to 0
    (7839) KING
    -- Commission reset to 0
    (7844) TURNER
    -- Commission: 0
    (7876) ADAMS
    -- Commission reset to 0
    (7900) JAMES
    -- Commission reset to 0
    (7902) FORD
    -- Commission reset to 0
    (7934) MILLER
    -- Commission reset to 0
    PL/SQL procedure successfully completed.
    SQL> select * from emp;
         EMPNO ENAME      JOB              MGR HIREDATE                    SAL       COMM     DEPTNO
          7369 SMITH      CLERK           7902 17-DEC-1980 00:00:00        800          0         20
          7499 ALLEN      SALESMAN        7698 20-FEB-1981 00:00:00       1600        300         30
          7521 WARD       SALESMAN        7698 22-FEB-1981 00:00:00       1250        500         30
          7566 JONES      MANAGER         7839 02-APR-1981 00:00:00       2975          0         20
          7654 MARTIN     SALESMAN        7698 28-SEP-1981 00:00:00       1250       1400         30
          7698 BLAKE      MANAGER         7839 01-MAY-1981 00:00:00       2850          0         30
          7782 CLARK      MANAGER         7839 09-JUN-1981 00:00:00       2450          0         10
          7788 SCOTT      ANALYST         7566 19-APR-1987 00:00:00       3000          0         20
          7839 KING       PRESIDENT            17-NOV-1981 00:00:00       5000          0         10
          7844 TURNER     SALESMAN        7698 08-SEP-1981 00:00:00       1500          0         30
          7876 ADAMS      CLERK           7788 23-MAY-1987 00:00:00       1100          0         20
          7900 JAMES      CLERK           7698 03-DEC-1981 00:00:00        950          0         30
          7902 FORD       ANALYST         7566 03-DEC-1981 00:00:00       3000          0         20
          7934 MILLER     CLERK           7782 23-JAN-1982 00:00:00       1300          0         10
    14 rows selected.Though, of course this is a pointless example as a simple single update would achieve the same. It's more useful if there are 'other things' you need to do with the data that would exceed the capabilities of just using SQL. Personally I've had little need to use this sort of construct.

  • Getting ORA-22920 Error With 'FOR UPDATE' clause

    Hello all,
    I scanned through all the messages regarding this error and the suggestion posted was to have 'FOR UPDATE' in the SELECT query. I do have that, but I am still getting ORA-22920 (row containing the LOB value is not locked) error.
    I am using JDBC thin driver with 8.0.5. I know the thin driver installation works because I can read data that I inserted using 'INSERT INTO ...' from svrmgr30.
    Can anyone show me some light on this?
    Thanks
    Suresh

    Hi,
    This helped me:
    Before the insert statement:
    connection.setAutoCommit(false);
    ..what you like to do
    at the end..
    connection.commit()
    HTH
    Martin

Maybe you are looking for