[ORACLE 9] Select For Update Nowait - Managing the Nowait

Hi,
Our application ( Oracle E Business R11) has a Form that allows Updates.
The problem is, when a user updates a record in the form, we want to prevent another user to open the same form, to avoid locks.
So I thought that I could
a) issue a 'select ...for update nowait',
b) get a code from Oracle
c )and use this code to prevent the form to be reopened.
I tried catching the Nowait in the exception section but I cannot get it to work.
Here is my code:
declare
  v_var varchar2(40) := '---';
lv_nom           tmp_delegue_jbm.del_nom%type;
begin
v_var := 'Phase 1';
select   del_nom
into     lv_nom
from     tmp_delegue_jbm
where    del_id = 3
for update of del_nom nowait;
dbms_output.put_line( 'Phase:  ' || v_var  );
v_var := 'Phase 2';
update tmp_delegue_jbm
set del_nom = del_nom || ' in'
where del_id = 3;
dbms_output.put_line( 'Phase:  ' || v_var  );
exception
   when others then -- Should deal with the nowait situation
         dbms_output.put_line( 'Error:  ' || v_var || ' - ' || sqlerrm );
end;
[End Code]
Many thanks                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

Far easier to poke a value into memory using DBMS_APPLICATION_INFO.SET_ACTION or SET_MODULE and have any session calling the form check first to see of another session has it already opened. Just make sure your exception handlers clear the lock.
http://www.morganslibrary.org/reference/dbms_applic_info.html

Similar Messages

  • Should i use SELECT for update NOWAIT ?

    Hi:
    Do I need to use, in my pl/sql triggers and procedures, the SELECT FOR UPDATE NOWAIT sentence, to avoid locks before using update table sentences ? Is it common to use it on stored procedures and triggers?
    Thanks
    Joao Oliveira

    First, what, exactly do you mean by "avoid locks"? I was interpreting that to mean "I want to avoid creating locks in my session that might block someone else", not "I want to avoid having my SELECT wait for locks to be released-- I want it to fail immediately". If you meant the latter, then SELECT ... FOR UPDATE NOWAIT would be what you want. If you meant the former, then pessimistic locking is not what you want.
    Second, what sort of Oracle Forms architecture do you have? Are you still using old-school client-server applications? Or are you using a three-tiered approach? As Tom discusses in that thread, pessimistic locking is only an option when your client application is able to maintain database state across calls (i.e. client/server systems) not when you have stateless connections (which is the norm in the three-tier model). The old client-server versions of Forms would automatically and transparently do pessimistic locking. Since you didn't mention anything about your architecture, most of us probably assumed the more common stateless client architecture (note how Tom's answers progress over the 5 years in that thread as client/server architecture became less and less common).
    Third, while your question is appropriate for either the Database - General forum or the SQL and PL/SQL forum, that generally means that you are free to post it either forum, not that it should be posted in both. The vast majority of the folks that hang out in one forum hang out in the other. It's also rather frustrating to answer a post in one forum only to discover that there is another post in a different forum where someone else had already covered the same points half an hour earlier or to discover that there was additional information in another thread that might have changed your answer.
    Fourth, if you are going to do pessimistic locking, that requires that you are able to maintain state across various database calls, that you are locking on the lowest possible level of granularity, and that you are able to time out sessions relatively aggressively to ensure that someone doesn't open a record, thereby locking it, go to lunch (or have their system die) and then block everyone else from working. Assuming that is the case, and that you have some reasonable way to handle the error that gets generated other than simply retrying the operation, adding NOWAIT is certainly an option. Most applications, particularly those getting written today, cannot guarantee all these things, so pessimistic locking is generally not appropriate there.
    Looking at your other thread (where there is new information that would be useful in this discussion, one of the reasons that multiple threads are generally a bad idea), it seems that you have an ERP application and you are concerned about the performance of entering orders. Obviously, there shouldn't be any locking issues on the ORDER or ORDER_DETAILS tables, assuming that multiple users aren't going to be inserting the same order at the same time. The contention would almost certainly come when multiple orders are trying to update the STOCK and INVENTORY tables, since multiple orders presumably rely on the same rows in those tables. In that case, I'm not sure what adding a NOWAIT would buy you-- unless you were going to roll back the entire order because someone is updating the STOCK row for #2 pencils and your order has an item of #2 pencils, you'd have to keep retrying the operation until you were able to modify the STOCK row, which would be less efficient than just letting that update block until the row was free.
    Now, you could certainly redesign the application to minimize that contention by not trying to update what I assume are aggregate tables like STOCK and INVENTORY directly as part of your OLTP processing or, at least, by minimizing the time that you're locking a row. You could, for example, make STOCK and INVENTORY materialized views rather than tables that refresh ON COMMIT, which should decrease the time that your locks are held. You could also have those tables refreshed asynchronously, which would be even more efficient but may require that you reasses your holdback requirements.
    Justin

  • SELECT FOR UPDATE NOWAIT

    Hi everyone!
    I have procedure that looks like this:
    procedure set_expired_users(
        p_QID   integer,
        p_Value integer default 1)
      is
        l_mdate timestamp(3) := null;
      begin
        l_mdate := get_mdate(p_Value);
        MERGE INTO cached_lists cl
        USING (SELECT distinct s.rootof as list_id, p_Value as is_expired, l_mdate as mdate
               FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
               WHERE  u.grp <> 1
                      AND f.userm = u.id
                      AND lt.id = z.id
                      AND f.userg = lt.ra
                      AND z.qid = p_QID
                      AND userm <> -2
                      AND s.ruser = userm) t
        ON (cl.list_id = t.list_id)
        when matched then
          UPDATE SET cl.is_expired = t.is_expired, cl.mdate = decode(t.mdate, null, cl.mdate, t.mdate)
        when not matched then
          INSERT VALUES (t.list_id, t.is_expired, l_mdate);
      end set_expired_users;As you can see there is no commit, commit executes in other stored procedures after that. in some cases I have bottleneck(enq TX), I rewrote procedure:
      procedure set_expired_users(
        p_QID   integer,
        p_Value integer default 1)
      is
        l_mdate timestamp(3) := null;
        busy_lock exception;
        PRAGMA exception_init(busy_lock,-54);
          cursor cur_upd  is
        SELECT 1 from cached_lists cl where cl.list_id in (SELECT distinct s.rootof as list_id
               FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
               WHERE  u.grp <> 1
                      AND f.userm = u.id
                      AND lt.id = z.id
                      AND f.userg = lt.ra
                      AND z.qid = p_QID
                      AND userm <> -2
                      AND s.ruser = userm) FOR UPDATE NOWAIT;
      begin
      open cur_upd;
        l_mdate := get_mdate(p_Value);
       MERGE INTO cached_lists cl
        USING (SELECT distinct s.rootof as list_id, p_Value as is_expired, l_mdate as mdate
               FROM   zzz_userrelflat f, zzz_users u, zzz_temp_nn z, speclists s, lists_table lt
               WHERE  u.grp <> 1
                      AND f.userm = u.id
                      AND lt.id = z.id
                      AND f.userg = lt.ra
                      AND z.qid = p_QID
                      AND userm <> -2
                      AND s.ruser = userm) t
        ON (cl.list_id = t.list_id)
        when matched then
          UPDATE SET cl.is_expired = t.is_expired, cl.mdate = decode(t.mdate, null, cl.mdate, t.mdate)
        when not matched then
          INSERT VALUES (t.list_id, t.is_expired, l_mdate);
            close cur_upd;  
          exception
      when busy_lock then
        null;
      end set_expired_users;Is this a good method to exclude enq TX?
    Sincerely,
    Pavel.

    In my opinion, you shouldn't rewrite that procedure, but you should rethink (ie. streamline) the overall transaction and try to reduce the wait times between the procedure call and the commit/rollback.

  • Oracle select for update: not releasing lock

    My JDBC code uses "select for update" to modify record in Oracle database. I tried to simulate network connection down situation.
    After my JDBC code locked on a record using "select for update", I unplugged the network cable. I then tried to run the same code on another computer, but it could not accquire the lock, because the previous lock was not released. I tried sqlplus to lock the record, but failed also. The lock has been there for at least an hour now. I guess it may finally be released, but is there a way for oracle to release the lock as soon as the connection is down? Not know if it is a JDBC setting or oracle setting.

    Dear Friend,
    What you are trying to do is not correct way of checking the concurrency and transaction.
    The reason is as listed below.
    01.Always remember http is a stateless protocol and removing the connection or just closing the browser will never be informed to the database or to the application server thus the transaction monitor (TM)or processor will never release the lock as it will deem that the actor is manipulating the data.
    02.As per locking goes every database is having a �TM� and the default isolation level setting is different like oracle uses serializable DB2udb 7.0 or db2/As400 uses repeatable read. You can change this setting by editing the default setting in the database but be very sure before touching it.
    03.     You can also transpose this with your Application server setting for that piece of code or Globally but again be very sure about it as it will change the entire gamete.
    04.     For releasing lock you have to manually do it or you can change the settings of App server or the Database to release the connection after some wait time.
    Regards,
    Ruchir

  • FOR UPDATE NOWAIT Fails to Detect Lock

    Locking a bitmap indexed row would cause other rows locked. I heard that, if FOR UPDATE NOWAIT is used on these accidentally locked rows (Oracle SQL High Performance Turning by Prentice hall), it may not be able to detect the lock. Is it true? I cannot find related documenation from Oracle's manual. And, what should we do to prevent an incorrect lock status returned by FOR UPDATE NOWAIT?

    SELECT FOR UPDATE NOWAIT detects locks affected DATA blocks.
    Look the example below:
    SQL> create table t1 (id number, bit_col number);
    Table created.
    SQL> begin
      2  insert into t1 values(0,1);
      3  insert into t1 values(1,1);
      4  insert into t1 values(2,2);
      5  insert into t1 values(3,3);
      6  insert into t1 values(4,4);
      7  end;
      8  /
    PL/SQL procedure successfully completed.
    SQL> commit;
    Commit complete.
    SQL> create bitmap index t1_bit on t1(bit_col);
    Index created.Now in session 1 we change the bitmap-indexed column and it affects
    index node:
    SQL> update t1
      2  set bit_col = 4
      3  where id = 2;
    1 row updated.In accordance to bitmap index structure this operator locks the index section
    the locked row pertains to:
    2th session waits for the lock release even when it tries to lock another row -
    two rows pertain to the same index section which is locked by the first session:
    SQL> update t1
      2  set bit_col = 2
      3  where id = 3;After rollback in the first session the second one gets the resource:
    SQL> update t1
      2  set bit_col = 2
      3  where id = 3;
    1 row updated.Now lets do rollback in both and repeate the first UPDATE in the first session:
    SQL> update t1
      2  set bit_col = 4
      3  where id = 2;
    1 row updated.In the second session we can lock the row (not index section) using
    SELECT FOR UPDATE:(in contrast with UPDATE statement which changes
    indexed column):
    SQL> select * from t1 where id=3 for update nowait;
            ID    BIT_COL
             3          3But certainly we detect row-level lock in the data block for ID = 2:
    SQL> select * from t1 where id=2 for update nowait;
    select * from t1 where id=2 for update nowait
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specifiedRgds.

  • Select for update on stateless connections

    i have read that using select for update for a web application will not work specially if the stateless connection are used , and the best way to make sure that the column you are reading was not changed is to use the time stamp approach and not select for update?? i am right

    Not entirely correct.
    A connection/session to Oracle has state. There is no such thing as a stateless Oracle connection.
    The stateless connection is from the web browser to the web server. It makes a connection. Asks for a page (GET, PUT or POST typically). It gets a response from the web server. It closes that connection.
    When the web server response, it opens a (stateful) connection to Oracle. Or it re-uses an existing (stateful) Oracle connection (now idle after having serviced another web browser/web server request).
    The problem with pessimistic locking (e.g. SELECT FOR UPDATE) is that the very same (stateful) Oracle session will either
    a) be closed when a response is send to the web browser
    b) be used for another totally different web browser
    Thus any locks made will either be lost (option a) or will get used by the wrong web browser (option b).
    A method is therefore needed to make the lock spans different Oracle (stateful) sessions. Web browser selects rows to update using Oracle session 101 at Time 1. Web browser submits updated rows and a commit using Oracle session 142 at Time 2.
    The "best way" to handle optimistic locking is likely using the Oracle System Change Number (SCN). This represents the "current version" of the rows.
    So at Time 1, via Session 101, you give the web browser a 100 rows to update - together with the SCN that says the current version of the rows are v1.2.0.1.
    At Time 2, using Session 142, the web browser submits its changes for those 100 rows. Together with the SCN v1.2.0.1.
    The SQL UPDATE issues the update statement - but adds the SCN version criteria. If the UPDATE fails to update all 100 rows, it means that some of the rows no longer exist, or that some rows have a new version number (was changed in the meantime).
    In this case, the UPDATE is rolled back and an exception raised to tell the web browser that some (or all) of those 100 rows have been changed in the meantime.
    Refer to the [url http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/pseudocolumns007.htm#BABFAFIC]Oracle® Database SQL Reference for details.

  • JDBC-thin on Solaris 2.7, 1002 on "FOR UPDATE NOWAIT"

    Has there been a patch to allow SELECT... FOR UPDATE NOWAIT
    in the jdbc thin connection layer?
    I have a program which runs transactions against Oracle 7.3 or
    8.05, and I'm finding that it works fine on my NT workstation
    against, 7.3.4....
    But when I run it against oracle 8.0.5 from a Solaris 2.7 system,
    I'm getting ORA-1002 errors whenever I select for update nowait.
    I'm oracle has a fix for this, but I haven't seen it yet.
    I did see a message about BUG 597589 posted on 02-Sep-1998.
    Was this ever fixed? The BUG database makes no mention of it.
    The only work-around seems to be to set autocommit, but I suspect
    that will lead to deadlocks in my application, if it even works!
    Has anyone else dealt with this problem?
    Thanks in advance,
    Kevin Fries
    null

    Has there been a patch to allow SELECT... FOR UPDATE NOWAIT
    in the jdbc thin connection layer?
    I have a program which runs transactions against Oracle 7.3 or
    8.05, and I'm finding that it works fine on my NT workstation
    against, 7.3.4....
    But when I run it against oracle 8.0.5 from a Solaris 2.7 system,
    I'm getting ORA-1002 errors whenever I select for update nowait.
    I'm oracle has a fix for this, but I haven't seen it yet.
    I did see a message about BUG 597589 posted on 02-Sep-1998.
    Was this ever fixed? The BUG database makes no mention of it.
    The only work-around seems to be to set autocommit, but I suspect
    that will lead to deadlocks in my application, if it even works!
    Has anyone else dealt with this problem?
    Thanks in advance,
    Kevin Fries
    null

  • SELECT FOR UPDATE via KODO queries

    I want to do the following in a transaction:
    1) SELECT * from Foo where type='x' FOR UPDATE
    2) UPDATE Foo set sequence='22' where type='x'
    3) commit
    The issue: is there any way to force KODO to add the 'for update' in a find query.
    Thanks

    Please try kodo.LockManager configuration property.
    -pessimistic: This is an alias for the kodo.jdbc.kernel.PessimisticLockManager , which uses SELECT FOR UPDATE statements (or the database's equivalent) to lock the database rows corresponding to locked objects. This lock manager does not distinguish between read locks and write locks; all locks are write locks.
    Also please make sure you have following setting
    kodo.jdbc.DBDictionary: SupportsSelectForUpdate=true
    Please check kodo doc section 9.4.4.
    JPA looks like
    <property name="kodo.LockManager" value="pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)"/>
    JDO looks like
    kodo.LockManager: pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)
    Thanks,
    Yun

  • Memory Leak - select for update

    Hi All.
    Doing an application using OCI 8.1.7 I faced with a memory leak. (or it seems to). The leak is caused by OCIStmtExecute with SELECT FOR UPDATE statement when the iters parameter of that function is 0. In all other cases it works Ok. Below you can find a code causes a leak:
    const char* sqlStatement = "select integercol from test_types for update";
    OCIStmt* ociStatementHandle = 0;
    OCIHandleAlloc(ociEnvHandle,(dvoid **)&ociStatementHandle,
    OCI_HTYPE_STMT, (size_t) 0, (dvoid **) 0));
    OCIStmtPrepare(ociStatementHandle, ociErrorHandle,
    (text*)sqlStatement, strlen(sqlStatement), OCI_NTV_SYNTAX, OCI_DEFAULT));
    int int_test;
    OCIDefine* ociDefineHandle = 0;
    OCIDefineByPos(ociStatementHandle, &ociDefineHandle, ociErrorHandle,
    1, (dvoid *)&int_test, (sword) sizeof(int), SQLT_INT, (dvoid *) 0, (ub2 *)0,
    (ub2 *)0, OCI_DEFAULT));
    ub4 iters = 0; // (0 causes a leak)
    for( int i=0; i < 100000; i++ )
    OCIStmtExecute(ociServiceHandle, ociStatementHandle, ociErrorHandle, iters, (ub4) 0, (CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT));
    If I change iter to 1 the leak disappears, but it is not suitable of course. Oracle documentation says following:
    iters (IN)
    For non-SELECT statements, the number of times this statement is executed is equal to iters - rowoff.
    For SELECT statements, if iters is non-zero, then defines must have been done for the statement handle. The execution fetches iters rows into these predefined buffers and prefetches more rows depending upon the prefetch row count. If you do not know how many rows the SELECT statement will retrieve, set iters to zero.
    This function returns an error if iters=0 for non-SELECT statements.
    Did somebody face the problem? Do you know how to fix it?
    null

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Bjorn Engsig ([email protected]):
    Are you saying, that the memory leak disappears if you don't do 'for update' in the query?
    Also, is the memory leak on the client or server side?<HR></BLOCKQUOTE>
    Yes, the leak appeares ONLY for 'select ... for update' statements.
    It is a client side leak, the client is Win2000.
    null

  • Audit "SELECT FOR UPDATE" statement

    Hi all
    My database is 10.2.0.3 and I enabled audit_trail to DB value already.
    My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
    So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
    Regards,
    Hiko

    taohiko wrote:
    Hi all
    My database is 10.2.0.3 and I enabled audit_trail to DB value already.
    My purpose I want to audit "SELECT FOR UPDATE" statement on the table and I tried to enable audit "SELECT" on the table that have many records in dba_audit_trail because "SELECT" statement that include in this audit and then I tried to enable audit "LOCK TABLE" on the table that doesn't have any records n dba_audit_trail.
    So my question is How to enable audit for collecting only "SELECT FOR UPDATE" statement? or anyone have any idea for this.
    A consideration on top of the comments made by Justin:
    You have an unfortunate version of the database for auditing: when you enable audit on 10.2.0.3 (or.2 or .1) the redo pattern changes - normally you will see a redo change vector for each row updated, but in these versions you will see two records, a "lock row" followed up "update row piece"; which means your volume of redo may increase significantly.
    I wrote a note about it some time ago: http://jonathanlewis.wordpress.com/2011/05/27/audit-ouch/ and one of the comments includes the bug number ( 5166745 ), reporting fixed in 10.2.0.4 and 11.1.0.6
    Regards
    Jonathan Lewis
    This is bug

  • Select for update that doesn't return any rows

    Are there any odd side-effects that may occur if a select for update that returns no results is never committed? I wouldn't think there are, but I'm not sure if there would be some kind of overhead or unforeseen consequences. This isn't a terribly important question, but it's come up in some coding I've done and I've not been able to find any documentation addressing it.

    A select for update only locks rows that meet the predicate specified in the where clause. So, if the query returns no rows, no rows are locked.
    session1> SELECT * FROM t;
            ID DESCR
             1 Un
             5 One
             2 THIS IS WA
    session1> SELECT * FROM t
      2  WHERE id = 11 FOR UPDATE;
    no rows selectedA second session can update rows in the table
    session2> UPDATE t
      2  SET descr = 'One'
      3  WHERE id = 1;
    1 row updated.John
    Edited by: John Spencer on Jan 7, 2009 1:36 PM
    I just realized that, although you can do updates on the table after the select fo update that returns no rows, you cannot do DDL operations liike a truncate. Unless the session that does the select for update either ends the transaction (i.e. commit or rollback) or ends the session DDL operations will fail.

  • When is SELECT FOR UPDATE used

    DB version:10gR2
    Since another thread of mine on this subject didn't go well, i am starting another thread.
    When exactly is SELECT..FOR UPDATE statement used? With the exception of using SELECT...FOR UPDATE in CURSOR declaration, I've rarely seen SELECT ...FOR UPDATE being used explicitlyby PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE(i mean a stand alone SELECT FOR UPDATE, <em>not as a part of Cursor</em>) to lock rows before UPDATE/DELETE/INSERT in their codes?
    Edited by: M.Everett on Oct 20, 2008 12:00 PM
    edited the initial post to let the users know that I am refering to a stand alone SELECT FOR UPDATE statement, not the part of a cursor

    M.Everett wrote:
    What i gather from various sources in the Internet:
    1. SELECT FOR UPDATE is used mainly on CURSORs and very rarely used as a stand alone statement (if this is not the case you would have seen SELECT FOR UPDATE statements before every UPDATEs and DELETEs in PL/SQL codes)
    2. Stand alone SELECT FOR UPDATEs are used mainly when dealing with CLOB, BLOB
    Am i right in making these conclusions?1. This is probably a fair assumption.
    2. Not really. SELECT FOR UPDATE is not a requirement when dealign with (C|B)LOBs.
    SELECT FOR UPDATE allows an easy form of reference when you come to update rows in a cursor loop (although cursor loops should be rarely used), because rather than having to include a where condition on key columns you can just refer to the CURRENT ROW. Obviously, the main reason for using SFUs is the locking and this can become a requirement in some business environments where a user "picks up" a record to deal with and other users will then not see that record in their list or be able to select it for themselves.
    ;)

  • Ansi SQL for "select ... for update nowait"

    Hi, All,
    I have a sql
    select ... for update nowait
    My boss wants it to be ANSI compliant.
    I am not familiar with ANSI SQL.
    What should be the syntax in Ansi?
    Thanks a lot!

    I resent having the lowest salary :-)Sorry John, it's probably due to the exchange rate of sterling against the canuck dollar right now.
    SQL> select empno, ename, sal, job, mgr from emp;
         EMPNO ENAME             SAL JOB              MGR
          7369 SPENCER           800 CLERK           7902
          7499 VERREYNNE        1600 SALESMAN        7698
          7521 VAN WIJK         1250 SALESMAN        7698
          7566 MAINGUY          2975 MANAGER         7839
          7654 KISHORE          1250 SALESMAN        7698
          7698 BARRY            2850 MANAGER         7839
          7782 BOEHMER          2695 MANAGER         7839
          7788 PADFIELD         3000 ANALYST         7566
          7839 SCHNEIDER        5500 PRESIDENT
          7844 GASPAROTTO       1500 SALESMAN        7698
          7876 CAVE             1100 CLERK           7788
          7900 CLARKE            950 CLERK           7698
          7902 JAFFAR           3000 ANALYST         7566
          7934 ROBERTSON        1430 CLERK           7782
    14 rows selected.
    SQL> Cheers, APC

  • Difference in select for update of - in Oracle Database 10g and 11g

    Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
    DECLARE
      v_ename bonus.ename%TYPE;
    BEGIN
      SELECT b.ename
        INTO v_ename
        FROM bonus b
        JOIN emp e ON b.ename = e.ename
        JOIN dept d ON d.deptno = e.deptno
       WHERE b.ename = 'Scott'
         FOR UPDATE OF b.ename;
    END;
    /While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
    Edited by: Libor Nenadál on 29.4.2010 21:46
    It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11g

    The behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).

  • I accidently deleted the playlist selected for updating thing...

    i was adding new songs to my ipod and i guess there were too many songs there so it asked me if i wanted it to choose some songs randomly...
    so i chose "ok" but actually i didnt really want it to choose songs on its own so i deleted the list that was automatically created by itself and decided to delete some songs on my own...
    after doin that, i tried to update it but now it says i cant do it because i deleted that list...
    it says "songs on the ipod "stephanie kim" cannot be updated because all of the playlists selected for updating no longer exists"
    i turned my computer off and tried it again several times but it wont work...
    and all the songs in my ipod are gone now...
    is there anything i can do?

    http://support.apple.com/kb/PH10918
    Best.

Maybe you are looking for

  • AP Supplier Open Interface

    I have a question about the Suppliers Open Interface. I am doing an R12 Conversion and Interface I designed the Conversion fine...but the interface logic confuses me a bit. I am aware most of the code will be the same. Maybe someone with working know

  • CreateTable statement fails..

    Hi, i'm quit new to Oracle. I'm trying to create a table through my webserver in our Oracle 10g database located on another server. I'm receiving the following error message: Microsoft OLE DB Provider for ODBC Drivers (0x80040E14) [Oracle][ODBC][Ora]

  • How to Rank

    How can we set up a question to rank multiple options in order of importance?

  • Editing Business content infocubes and transfer structure

    Please till me how to edit the installed business content cube , update rules and transfer structure.Once installed means where we can see the installed cube.

  • Simple Module Pool ?

    Hi experts, In module pool is it possible to pass values to push button dynamically from internal table after PBO.If so give me some ideas how to pass values.the push button values also based on internal table values.I am using table control display