SINGLE FOR UPDATE

Hi,
can anybody tell me the user of "SINGLE FOR UPDATE" keywords in SELECT statement?
Priya

As given by SAP -
... SINGLE [FOR UPDATE]
If SINGLE is specified, the resulting set has a single line. If the remaining additions to the SELECT command select more than one line from the database, the first line that is found is entered into the resulting set. The data objects specified after INTO may not be internal tables, and the APPENDING addition may not be used. The addition ORDER BY can also not be used.
An exclusive <b>LOCK</b> can be set for this line using the FOR UPDATE addition when a single line is being read with SINGLE. The SELECT command is used in this case only if all primary key fields in logical expressions linked by AND are checked to make sure they are the same in the WHERE condition. Otherwise, the resulting set is empty and sy-subrc is set to 8. If the lock causes a deadlock, an exception occurs. If the FOR UPDATE addition is used, the SELECT command circumvents SAP buffering.
LOCK - Lock protected data from being accessed by several users at the same time as a shared lock or as exclusive locks
Regards,
Amit
Reward all helpful replies.

Similar Messages

Select single for update not creating lock on entry

Hi All,
I want to update an entry from MARA table so what ii did is
select single for update *   from mara where matnr = 'ZYS'.
The for update is supposed to create a lock for me and the the lock is released after the commit or roll back.
I'm running this prg in debug mode and after the statment
select single for update *   from mara where matnr = 'ZYS''.
I opened MM02 for this material and could change the data which i'm not supposed to be as there is lock on this particular mater from single for update statemnt
or
I even tried from other program
select single *   from mara where matnr = 'ZYS'. in debug mode and it returned a sy-subrc eq 0.
and i don't see a lock in SM12 FOR SELECT * FOR UPDATE.....
Can anyone clarify on this
Thanks
David

Hi All,
I knew we can create a lock object but thought to give a shot without creating lock object.
So i'm just curious to know when we can use select * for update
F1 Help says select * for update creates an E type lock- which will prevent other locks(X AND S type locks) overwriting or even reading that entry
Also ,
can someone throw some light DB lock and SAP Lock ( is this same as SAP LUW and DB LUW)
Thanks
David

Use of SELECT SINGLE FOR UPDATE

Hello,
Am I missing something with FOR UPDATE addition in Open SQL? When I use it I can't get a lock to appear to SM12. For example, if I select a single record for update from table EKKO it's still possible to effect a normal MEPO update of the releavnt purchase order even before a COMMIT WORK command in my code.
Any ideas?
Thanks,
Chris.

Hello Chris
FOR UPDATE command creates only a database lock,
you can't see database locks in sm12.
You should use related "lock object" to lock entries in table EKKO with sm12
For finding the lock object follow steps below :
- Go to transaction se11
- Write your table EKKO
- Click button : Where Used List
- Choose only "Lock object" in the next popup screen
Every lock object has two function module ENQUEUE_<LOCK OBJ NAME> and DEQUEUE_<LOCK OBJ NAME>
enqueue function creates lock in sm12 and dequeue deletes lock entry from sm12.
And you can display parameters from se37 and use it.
I hope it helps.

Re: Transactions and Locking Rows for Update

Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - Calvin

We have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]>

Transactions and Locking Rows for Update

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
[email protected]------------------

How do I allow offline use AND check for updates if online?

I am actually not sure if this is a bug or not, as the behavior changed when I updated from 1.6u20 to u21. I have an application in a single JAR, and a JNLP file. I am testing with Windows 7 64-bit (with both the 32- and 64-bit version of the JVM installed, 1.6u20-b06 on both). The application cache is enabled. Here is my JNLP file:
<?xml version="1.0" encoding="us-ascii"?>
<jnlp
spec="6.0+"
codebase="http://hidden"
href="Librarian.jnlp">
<information>
    <title>Librarian</title>
    <vendor>Vendor</vendor>
    <homepage href="http://hidden"/>
    <description>Description.</description>
    <offline-allowed/>
    <shortcut online="false">
      <desktop/>
      <menu submenu="Vendor"/>
    </shortcut>
    <icon href="Librarian.gif"/>
</information>
<security>
    <all-permissions/>
</security>
<resources>
    <j2se version="1.6+"/>
    <jar href="Librarian.jar" main="true"/>
</resources>
<application-desc main-class="com.vendor.apps.librarian.Librarian"/>
</jnlp>I am observing the following behavior wrt updates and allow-offline:
When allow-offline is present:
- JWS does not download updates to the JAR file when the desktop link is clicked.
- The application can run when I disable the network connection.
- The "-offline" switch is passed to javaw in the desktop shortcut.
When allow-offline is not present:
- JWS does download JAR updates when the desktop link is clicked.
- The application can not run when I disable the network connection (HostNotFoundException).
- The "-offline" switch is not passed to javaw in the desktop shortcut.
What I want to happen is for JWS to check for updates if it can, and if it times out, instead of barfing, just go ahead and run the cached version. What I can get right now is either no updates + offline allowed, or updates + offline disallowed. However, I can obtain the behavior I want if I specify allow-offline then hand-edit the desktop shortcut and remove "-offline":
When allow-offline is present but I remove "-offline" from the desktop shortcut:
- JWS does download updates to the JAR file.
- The application can run when I disable the network connection, after a short timeout.
Now, I was under the impression that this behavior is the intended behavior of allow-offline: attempt to download update, on error, silently start the cached version instead. This does not seem to be the case. I actually wonder if this is a bug, as with 1.6u20, it seemed to download JAR updates just fine when allow-offline was specified (I had issues when the cache was disabled with 1.6u20, and so I moved to u21).
How can I make this work the way I want without having to hand edit the desktop shortcut?
Is this a bug, or am I misconfiguring (OED says this is a real word!) the application?
Is there something else I have to do to indicate that the JAR is updated besides just uploading a new version to the server?
It should be noted that I am not doing any web page magic here, I'm testing by simply downloading the JNLP file off the server and opening it. This is actually my first JWS experience and I haven't gotten to properly embedding it in a web page yet. I do not know if this is significant or not.
Thanks!
M

Well, I solved that quick. I've been staring at it for over an hour but it popped out at me as soon as I looked at my JNLP file in my post here (guess it's the red text, heh).
All I need to do is set online="true" in the shortcut, and also specify allow-offline, and all works exactly as I want it to. :-)
Perhaps it was a bug in u20 that was causing it to check for updates anyways even with an offline shortcut... I'm not sure, and I don't have it in me to test it any more at the moment.
Thanks,
M

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.

How do I turn off the automatic check for update on opening Firefox? I want to turn off that "what's new" page.

How do I turn off that automatic update that always brings me to the "what's new" web page? It was interesting the first time, but now it is just an irritation. I can check for updates on my own, so I want to turn off this feature. It just started up when I upgraded to Firefox 5. I can't find a place to stop it from checking and bringing me to that web page. Also, I can't stop it from checking add-ons every single time I open the browser.

did you check the suggestions mentioned in the article i posted in my previous post ??

FOR UPDATE cursor is causing Blocking/ Dead Locking issues

Hi,
I am facing one of the complex issues regarding blocking / dead locking issues. Please find below the details and help / suggest me the best approach to ahead with that.
Its core Investment Banking Domain, in Our Day to day Business we are using many transaction table for processing trades and placing the order. In specific there are two main transaction table
1)     Transaction table 1
2)     Transaction table 2
These both the tables are having huge amount of data. In one of our application to maintain data integrity (During this process we do not want other users to change these rows), we have placed SELECT …………….. FOR UPDATE CURSOR on these two table and we have locked all the rows during the process. And we have batch jobs (shell scripts ) , calling this procedure , we will be running 9 times per day 1 hrs each start at 7:15AM in the morn finish it up in the eve 5PM . Let’s say. The reason we run the same procedure multiple times is, our business wants to know the voucher before its finalized. Because there is a possibility that order can be placed and will be updated/cancelled several times in a single day. So at the end of the day , we will be sending the finalized update to our client.
20 07 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 08 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 09 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 10 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 11 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 12 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 13 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 14 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 15 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 16 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
20 17 * * 1-5 home/bin/app_process_prc.sh >> home/bin/app1/process.out
Current Program will look like:
App_Prc_1
BEGIN
/***** taking the order details (source) and will be populate into the table ****/
CURSOR Cursor_Upload IS
SELECT col1, col2 … FROM Transaction table1 t 1, Source table 1 s
WHERE t1.id_no = t2.id_no
AND t1.id_flag = ‘N’
FOR UPDATE OF t1.id_flag;
/************* used for inserting the another entry , if theres any updates happened on the source table , for the records inserted using 1st cursor. **************/
CURSOR cursor_update IS
SELECT col1, col2 … FROM transaction table2 t2 , transaction table t1
WHERE t1.id_no = t2.id_no
AND t1.id_flag = ‘Y’
AND t1.DML_ACTION = ‘U’,’D’ -- will retrieve the records which are updated and deleted recently for the inserted records in transaction table 1 for that particular INSERT..
FOR UPDATE OF t1.id_no,t1.id_flag;
BLOCK 1
BEGIN
FOR v_upload IN Cursor_Upload;
LOOP
INSERT INTO transaction table2 ( id_no , dml_action , …. ) VALUES (v_upload.id_no , ‘I’ , … ) RETURNING v_upload.id_no INTO v_no -- I specify for INSERT
/********* Updating the Flag in the source table after the population ( N into Y ) N  order is not placed yet , Y  order is processed first time )
UPDATE transaction table1
SET id_FLAG = ‘Y’
WHERE id_no = v_no;
END LOOP;
EXCEPTION WHEN OTHER THEN
DBMS_OUTPUT.PUT_LINE( );
END ;
BLOCK 2
BEGIN -- block 2 starts
FOR v_update IN Cursor_Update;
LOOP;
INSERT INTO transaction table2 ( id_no ,id_prev_no, dml_action , …. ) VALUES (v_id_seq_no, v_upload.id_no ,, … ) RETURNING v_upload.id_no INTO v_no
UPDATE transaction table1
SET id_FLAG = ‘Y’
WHERE id_no = v_no;
END LOOP;
EXCEPTION WHEN OTHER THEN
DBMS_OUTPUT.PUT_LINE( );
END; -- block2 end
END app_proc; -- Main block end
Sample output in Transaction table1 :
Id_no | Tax_amt | re_emburse_amt | Activ_DT | Id_Flag | DML_ACTION
01 1,835 4300 12/JUN/2009 N I ( these DML Action will be triggered when ever if theres in any DML operation occurs in this table )
02 1,675 3300 12/JUN/2009 Y U
03 4475 6500 12/JUN/2009 N D
Sample output in Transaction table2 :
Id_no | Prev_id_no Tax_amt | re_emburse_amt | Activ_DT
001 01 1,835 4300 12/JUN/2009 11:34 AM ( 2nd cursor will populate this value , bcoz there s an update happened for the below records , this is 2nd voucher
01 0 1,235 6300 12/JUN/2009 09:15 AM ( 1st cursor will populate this record when job run first time )
02 0 1,675 3300 12/JUN/2009 8:15AM
003 03 4475 6500 12/JUN/2009 11:30 AM
03 0 1,235 4300 12/JUN/2009 10:30 AM
Now the issues is :
When these Process runs, our other application jobs failing, because it also uses these main 2 tranaction table. So dead lock is detecting in these applications.
Solutin Needed :
Can anyone suggest me , like how can rectify this blocking /Locking / Dead lock issues. I wants my other application also will use this tables during these process.
Regards,
Maran

hmmm.... this leads to a warning:
SQL> ALTER SESSION SET PLSQL_WARNINGS='ENABLE:ALL';
Session altered.
CREATE OR REPLACE PROCEDURE MYPROCEDURE
AS
   MYCOL VARCHAR(10);
BEGIN
   SELECT col2
   INTO MYCOL
   FROM MYTABLE
   WHERE col1 = 'ORACLE';
EXCEPTION
   WHEN PIERRE THEN
      NULL;
END;
SP2-0804: Procedure created with compilation warnings
SQL> show errors
Errors for PROCEDURE MYPROCEDURE:
LINE/COL                                                                          ERROR
     12/9        PLW-06009: procedure “MYPROCEDURE” PIERRE handler does not end in RAISE or RAISE_APPLICATION_ERROR
     :)

BADI or function module for updating open purchase orders

Hi all,
Does anyone know of a BADI or function module which can be used for updating item prices in open purchase orders?
All helpful answers are highly appreciated!
Regards,
MV

1 ) execute this program in se38 .enter the input as transaction code for which you want list of User
Exit.
REPORT z_find_userexit NO STANDARD PAGE HEADING.
*& Enter the transaction code that you want to search through in order
*& to find which Standard SAP® User Exits exists.
*& Tables
TABLES : tstc,     "SAP® Transaction Codes
         tadir,    "Directory of Repository Objects
         modsapt, "SAP® Enhancements - Short Texts
         modact,   "Modifications
         trdir,    "System table TRDIR
         tfdir,    "Function Module
         enlfdir, "Additional Attributes for Function Modules
         tstct.    "Transaction Code Texts
*& Variables
DATA : jtab LIKE tadir OCCURS 0 WITH HEADER LINE.
DATA : field1(30).
DATA : v_devclass LIKE tadir-devclass.
*& Selection Screen Parameters
SELECTION-SCREEN BEGIN OF BLOCK a01 WITH FRAME TITLE text-001.
SELECTION-SCREEN SKIP.
PARAMETERS : p_tcode LIKE tstc-tcode OBLIGATORY.
SELECTION-SCREEN SKIP.
SELECTION-SCREEN END OF BLOCK a01.
*& Start of main program
START-OF-SELECTION.
Validate Transaction Code
SELECT SINGLE * FROM tstc
    WHERE tcode EQ p_tcode.
Find Repository Objects for transaction code
IF sy-subrc EQ 0.
    SELECT SINGLE * FROM tadir
       WHERE pgmid    = 'R3TR'
         AND object   = 'PROG'
         AND obj_name = tstc-pgmna.
    MOVE : tadir-devclass TO v_devclass.
    IF sy-subrc NE 0.
      SELECT SINGLE * FROM trdir
         WHERE name = tstc-pgmna.
      IF trdir-subc EQ 'F'.
        SELECT SINGLE * FROM tfdir
          WHERE pname = tstc-pgmna.
        SELECT SINGLE * FROM enlfdir
          WHERE funcname = tfdir-funcname.
        SELECT SINGLE * FROM tadir
          WHERE pgmid    = 'R3TR'
            AND object   = 'FUGR'
            AND obj_name = enlfdir-area.
        MOVE : tadir-devclass TO v_devclass.
      ENDIF.
    ENDIF.
Find SAP® Modifications
    SELECT * FROM tadir
      INTO TABLE jtab
      WHERE pgmid    = 'R3TR'
        AND object   = 'SMOD'
        AND devclass = v_devclass.
    SELECT SINGLE * FROM tstct
      WHERE sprsl EQ sy-langu
        AND tcode EQ p_tcode.
    FORMAT COLOR COL_POSITIVE INTENSIFIED OFF.
    WRITE:/(19) 'Transaction Code - ',
    20(20) p_tcode,
    45(50) tstct-ttext.
    SKIP.
    IF NOT jtab[] IS INITIAL.
      WRITE:/(95) sy-uline.
      FORMAT COLOR COL_HEADING INTENSIFIED ON.
      WRITE:/1 sy-vline,
      2 'Exit Name',
      21 sy-vline ,
      22 'Description',
      95 sy-vline.
      WRITE:/(95) sy-uline.
      LOOP AT jtab.
        SELECT SINGLE * FROM modsapt
        WHERE sprsl = sy-langu AND
        name = jtab-obj_name.
        FORMAT COLOR COL_NORMAL INTENSIFIED OFF.
        WRITE:/1 sy-vline,
        2 jtab-obj_name HOTSPOT ON,
        21 sy-vline ,
        22 modsapt-modtext,
        95 sy-vline.
      ENDLOOP.
      WRITE:/(95) sy-uline.
      DESCRIBE TABLE jtab.
      SKIP.
      FORMAT COLOR COL_TOTAL INTENSIFIED ON.
      WRITE:/ 'No of Exits:' , sy-tfill.
    ELSE.
      FORMAT COLOR COL_NEGATIVE INTENSIFIED ON.
      WRITE:/(95) 'No User Exit exists'.
    ENDIF.
ELSE.
    FORMAT COLOR COL_NEGATIVE INTENSIFIED ON.
    WRITE:/(95) 'Transaction Code Does Not Exist'.
ENDIF.
Take the user to SMOD for the Exit that was selected.
AT LINE-SELECTION.
GET CURSOR FIELD field1.
CHECK field1(4) EQ 'JTAB'.
SET PARAMETER ID 'MON' FIELD sy-lisel+1(10).
CALL TRANSACTION 'SMOD' AND SKIP FIRST SCREEN.
2) Second way is to go to transaction code SE93 .enter transaction code click on display.
There you will see the package. Copy that package name.
Go to transaction code se84
Enhancements -customer exits-enhancementsu2014enter package there and execute.
You will get list of exits.
3) BAPI for PO change is
BAPI_PO_CHANGE

Problem combining select, order by, rownum (top-N) and for update

Hello,
i have serious problems with this.
-- drop table testtable;
create table testTable (id number(10,0) primary key, usage number(10,10));
-- delete from testtable;
insert into testtable values (11, 0.5);
insert into testtable values (10, 0.3);
insert into testtable values (12, 0.3);
insert into testtable values (9, 0.3);
insert into testtable values (8, 0.9);
insert into testtable values (3, 0.0);
insert into testtable values (2, 0.02);
insert into testtable values (1, 0.05);
insert into testtable values (7, 0.7);
insert into testtable values (6, 0.4);
insert into testtable values (5, 0.2);
insert into testtable values (4, 0.1);
select * from testtable;
-- without FOR UPDATE
select * from (
select tt.id id_, tt.*
from testtable tt
where tt.usage > 0.1
order by tt.usage desc, tt.id desc
where rownum <= 10;
--> WORKS
-- without ORDER BY
select * from (
select tt.id id_, tt.*
from testtable tt
where tt.usage > 0.1
where rownum <= 10
for update of id_;
--> WORKS
-- without WHERE ROWNUM <= 10
select * from (
select tt.id id_, tt.*
from testtable tt
where tt.usage > 0.1
order by tt.usage desc, tt.id desc
for update of id_;
--> WORKS
-- But what i need is this:
select * from (
select tt.id id_, tt.*
from testtable tt
where tt.usage > 0.1
order by tt.usage desc, tt.id desc
where rownum <= 10
for update;
--> ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc., SQL State: 42000, Error Code: 2014
select * from (
select tt.id id_, tt.*
from testtable tt
where tt.usage > 0.1
order by tt.usage desc, tt.id desc
where rownum <= 10
for update of id_;
--> ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc., SQL State: 42000, Error Code: 2014
I have tried every single solution i could come up with.
But nothing worked.
My latest idea is to include a comment in the query and set up an ON SELECT trigger which evaluates the comment and enforeces the lock.
But i'm not sure if this is even possible.
I cannot split the statement into two because i need the lock immediately when the wanted rows are selected.
One major criteria for the rows is the order by. Without it i get a random set of rows.
And the rownum <= 10 is also needed because i don't want to lock the whole table but only the few needed rows.
I tried row_number() over (order by ...) but this is considdered a window/group-function which disallows the for update as well as the order by.
During these tests i noticed, that when using the row_number()-function the resultset is ordered automatically (without an additional order by clause).
But this doesn't help anyway.
I tried using piped functions to wrap the select to apply the rownum manually by cursor skip, but this doesn't work either. First of all i wasn't able to wrap the query the way i imagined and second the lock would be applied to the whole resultset anyway but only the reduced rows would be returned.
I heared about LOCK-hints from other DBs, is there anything similar here?
Any other solution??
btw. it has to be high-performance after all.
Greetings Finomosec;

No, not perfect.
This is the expected result (ordered by usage desc, id desc):
ID     USAGE
8     0.9
7     0.7
11     0.5
6     0.4
12     0.3
10     0.3
9     0.3
5     0.2
This ist the one produced by your statement:
ID     USAGE
5     0.2
6     0.4
7     0.7
8     0.9
9     0.3
10     0.3
11     0.5
12     0.3
Use limit 5 in your tests, and you will also notice that the following doesn't work either:
select * from testtable ww where ww.id in
select id from
select tt.id, tt.usage
from testtable tt
where tt.usage > 0.1
where rownum <= 5
order by usage desc, id desc
for update;
It's because the order is not applied to the result.
But the following modification works (at least principally):
select * from testtable ww where ww.id in
select id from
select tt.id, tt.usage
from testtable tt
where tt.usage > 0.1
order by usage desc, id desc
where rownum <= 5
order by usage desc, id desc
for update;
Thr problem here is:
I need to expand the following Statement to the above form by (Java-) Code:
-- statement-A
select tt.id, tt.usage
from testtable tt
where tt.usage > 0.1
order by usage desc, id desc;
The main problem is:
The order by clause needs to be duplicated.
The problem here is, to identify it (if present) and NOT any order by in inner selects.
I am using Hibernate and to implement this i have to modify the OracleDialect to solve this problem. I get the statement-A (see above) and have to apply the limit.
Isn't there any other solution??
Greetings Finomosec;

Update my app. What is the correct procedure for updating an app/folio?

I designed a folio in Indesign CS6 and created an app of the folio in adobe dps and succesfully uploaded it to the app store. Now I want to update my app. What is the correct procedure for updating an app/folio?

no, just update your content and recreate the Single Edition App. Your certificate should still be valid so there is not need to recreate these.
... your App ID absolutely need to be the exact same one you used for the first version if you want to make sure this is an update.

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.

IMPORTANT: SQL Developer 1.2.1 Check For Updates Notice

Please note:
The Check For Updates notification yesterday and today (16th or 17th Aug) included a file with a number mismatch. This caused SQL Developer to continue to prompt for new Updates. This is also why a new installation of SQL Developer 1.2.1.32.00 prompted for Updates. This error has been repaired. You can now use Check for Updates to update from SQL Developer 1.2 to 1.2.1.
It remains true that after you have run Check for Updates that you must do a second restart. This is related to the framework and is a known issue.Without the second restart you will not be able to invoke the SQL Worksheet.
We have identified 2 errors that will be addressed, with new updates sent out using Check for Updates as soon as we can. These two errors are that reports with Charts do not currently work, and non-privileged users can't view tables.
The team apologizes for the inconvenience.
Regards
Sue Harper
Product Manager

Hello Sue,
I just proceeded the update on my working machine too.
The version number what I talked about (on this machine) was 1.1.2.25 before and still is the same after the update.
(This is different from my home machine.)
By the way - I had to restart SQL Dev two times before it realized, that it already has the latest updates. One restart still seems to be not enough.
Yes I know that all the extensions has it's own versions.
But for me the question remains: What is the version info under "Help-> About" (in my case 1.1.0.21.) good for? If this number has a meaning - what is it? and if it has no meaning (and only the version number of every single extension is interesting) why does these version number exist at all?
You said: until then I recommend you use the full download.
Question: Is it guarantied, that (at any time) the full download always has all latest extensions ?
Regards
Andre

SINGLE FOR UPDATE

Similar Messages

Maybe you are looking for