Reg : Concept of Locks --

Hi Experts,
I've got few doubts understanding the concepts of Locking.
I'm referring this article - http://docs.oracle.com/cd/E14072_01/server.112/e10592/ap_locks001.htm
1]
>
When a transaction obtains a row lock for a row, the transaction also acquires a table lock for the table in which the row resides.
The table lock prevents conflicting DDL operations that would override data changes in a current transaction.
>
What is the significance of the 2 ^nd^ line? Does that mean, at that time we can't DROP or ALTER the table structure ??
Although, it is written very clear manner, i'm not able to understand it properly.
2]
>
A row share lock (RS), also called a subshare table lock (SS), indicates that the transaction holding the lock on the table has locked some rows in the table and intends to update them, as is the case in a SELECT ... FOR UPDATE statement. An SS lock is the least restrictive mode of table lock, offering the highest degree of concurrency for a table.
A row exclusive lock (RX), also called a subexclusive table lock (SX), indicates that the transaction holding the lock has made updates to rows in the table. An SX lock by itself allows other transactions to insert, update, merge into, or delete other rows in the table concurrently. Therefore, SX locks allow multiple transactions to obtain simultaneous SX and SS locks for the same table.
>
- What is the need of an SX lock when it allows other transactions to manipulate data?
- Both SS and SX look like same kind of locks. Can any one please point out the difference with an example.
3]
>
A share table lock (S) held by one transaction allows other transactions to query the table but allows updates only if a share table lock is held by only a single transaction. Multiple transactions may hold a share table lock concurrently, so holding this lock is not sufficient to ensure that a transaction can modify the table.
A share row exclusive table lock (SRX), also called a share-subexclusive table lock (SSX), is more restrictive than a share table lock. Only one transaction at a time can acquire an SSX lock on a given table. An SSX lock held by a transaction allows other transactions to query or lock specific rows using SELECT ... FOR UPDATE, but not to update the table.
An exclusive table lock (X) is the most restrictive mode of table lock, allowing the transaction that holds the lock exclusive write access to the table. Only one transaction can obtain an X lock for a table.
>
I'm also little confused with these locking types and not able to understand the difference practically. I know these are very important concepts and should not be neglected.
Can any one please help me understand these concepts?
Thanks In Advance,
Ranit B.
Edited by: ranit B on Nov 28, 2012 6:47 PM
-- added [3]

padders wrote:
Does that mean, at that time we can't DROP or ALTER the table structure Yes, that's pretty much what it means.
What is the need of an SX lock when it allows other transactions to manipulate data?As the text says - the lock allows concurrent update of other rows - i.e. you lock some row(s) but other rows can still be updated.Thanks Padders.
But then, what is the difference between SS and SX? Both allow other rows to be updated.
Please rectify me if I'm wrong.
I got some idea. It would be really helpful if you could please give me some pointers on the other doubts also?

Similar Messages

  • Reg database logical locks

    hii all,
         I want to keep locks(logically) to the existing database records as my ztables(3 tables with 1 parent table,containing header data and 2 line item tables having the foreign key relationships with header table) are accessed at time by many users(different users might try to change the same record).what is the best way to go ahead.
    with regards,
    sandeep akella.

    Hi,
    check the following link
    http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4c5a79e11d1950f0000e82de14a/content.htm
    Regards,
    Madhu

  • Reg: concept of COUNT and NULLs -

    Hi Experts,
    I have a simple conceptual doubt regarding COUNT and NULLs.
    Even I have experimented and can justify the behaviour, just need to confirm once with guru's and experts over here.
    Workout:
    CREATE TABLE test_x1
    AS
    SELECT 1 col1, 'a' col2, 'a1' col3 FROM dual UNION ALL
    SELECT 2 col1, 'a' col2, 'a1' col3 FROM dual UNION ALL
    SELECT 3 col1, 'a' col2, 'a1' col3 FROM dual UNION ALL
    SELECT 4 col1, 'a' col2, 'a1' col3 FROM dual UNION ALL
    SELECT 5 col1, 'a' col2, 'a1' col3 FROM dual UNION ALL
    SELECT 6 col1, 'a' col2, NULL col3 FROM dual UNION ALL
    SELECT NULL col1, NULL col2, NULL col3 FROM dual UNION ALL
    SELECT 8 col1, 'a' col2, NULL col3 FROM dual;
    SELECT
      Count(*),
      Count(col1),
      Count(col2),
      Count(col3)
    FROM test_x1;
    COUNT(*) COUNT(COL1) COUNT(COL2) COUNT(COL3)
           8           7           7           5
    My justification:
    COUNT(*) - It counts for physical *rowid* ,and doesn't bother to check if data in the columns is it NULL or anything else.
    Whereas, COUNT(<column>) - just scans/counts the known values and NOT NULLs.
    Is the above correct? Please advise me on this.
    -- Ranit

    it's documented: http://docs.oracle.com/cd/E11882_01/server.112/e41084/functions039.htm#SQLRF00624
    If you specify expr, then COUNT returns the number of rows where expr is not null. You can count either all rows, or only distinct values of expr.
    If you specify the asterisk (*), then this function returns all rows, including duplicates and nulls. COUNT never returns null.
    So the answer is: yes.

  • Lock concept

    Hi peers,
    what does the _scope parameter specify in the enque<xxxx> and dequeue<xxxxx> function modules in locking concept.  what does _scope = '3' mean.

    Parameters for Passing Locks to the Update Program
    A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case, a parameter must check that the lock has been removed.
    Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
    &#65399;        _SCOPE = 1: Locks or lock releases are not passed to the update program. The lock is removed when the transaction is ended.
    &#65399;        _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
    &#65399;        _SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
    Function Modules for Lock Requests
    Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
    The generated function modules are automatically assigned to function groups. You should not change these function modules and their assignment to function groups since the function modules are generated again each time the lock object is activated.
    Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.
    Parameters of the Function Modules
    Field Names of the Lock Object
    The keys to be locked must be passed here.
    A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
    Parameters for Passing Locks to the Update Program
    A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case, a parameter must check that the lock has been removed.
    Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
    &#65399;        _SCOPE = 1: Locks or lock releases are not passed to the update program. The lock is removed when the transaction is ended.
    &#65399;        _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
    &#65399;        _SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
    Parameters for Lock Mode
    A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. The values allowed for this parameter are S (read lock), E (write lock), X (extended write lock), and O (optimistic lock).
    The lock mode specified when the lock object for the table is created is the default value for this parameter. This default value can, however, be overridden as required when the function module is called.
    If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
    Controlling Lock Transmission
    Parameter _COLLECT controls whether the lock request or lock release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values:
    &#65399;        Initial Value: The lock request or lock release is sent directly to the lock server.
    &#65399;        X: The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
    Whenever you have lock mode X (extended write lock), locks should not be written to the local lock container if very many locks refer to the same lock table. In this case, there will be a considerable loss in performance in comparison with direct transmission of locks.
    Behavior for Lock Conflicts (ENQUEUE only)
    The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
    You have the following options:
    &#65399;        Initial Value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
    &#65399;        X: If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
    Controlling Deletion of the Lock Entry (DEQUEUE only)
    The DEQUEUE function module also has the parameter _SYNCHRON.
    If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.
    Exceptions of the ENQUEUE Function Module
    &#65399;        FOREIGN_LOCK’: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
    &#65399;        SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
    If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
    Reference Fields for RFC-Enabled Lock Objects
    The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
    Parameters
    Reference fields
    X_<field name>
    DDENQ_LIKE-XPARFLAG
    _WAIT
    DDENQ_LIKE-WAITFLAG
    _SCOPE
    DDENQ_LIKE-SCOPE
    _SYNCHRON
    DDENQ_LIKE-SYNCHRON
    See also:
    Example for Lock Objects

  • Problem in lock Sales order create with BAPI BAPI_SALESORDER_CREATEFROMDAT2

    Hi All,
    i have the z program to create the sales order with reff  quotation in SD With BAPI BAPI_SALESORDER_CREATEFROMDAT2.
    this program will  excute every 30 mins .
    Problem: Some times if i excute the program in background it is taking morethan 30mins so second batch excution also gets starting to create the sales order for same quotation then it is creating 2 sales orders at atime with 1 quotation.
    here i am getting duplicate sales orders so i want to lock the creation of duplicate sales order.

    Some solutions
    - Just lock (ENQUEUE) any object at the start of the job(*), if not locked, you can exit or wait in a loop, will be released at end of job (use a _SCOPE '3' so commit work wont release the lock)
    -> This will insure the job runs only once at a time
    - Lock the quotation before calling the BAPI, will be released by the COMMIT_WORK (from where do you fetch the quotation, if it is a customer Z_table, you can use the lock object that you have surely created ?) (use a _scope '2')
    -> This will insure that at most one job will convert a quotation (i suppose you set a "done" flag or status  in the quotation record)
    Read [SAP Locks |http://help.sap.com/abapdocu_70/en/ABENSAP_LOCK.htm] if you are not familiar with the concept of lock in SAP.
    Regards,
    Raymond
    (*) E_TABLEE for table, E_TRDIR for program, anything not required by another process

  • Audio tracks: lock vs disconnect?

    Hi, all. I'm new to iMac and FCE Express. I'm not sure I understand the functional difference between locking the audio tracks versus disconnecting them. Don't both functions do the same thing?
    Thanks,
    Jeff

    Yes, I guess I'm referring to the patch panel.
    So you're saying that if I UNpatch, say, an audio track, and I have a clip in the Viewer that has both video AND audio, moving it to the timeline with the UNpatched audio track will move the video portion only, and not the new clip's audio?
    I'm sorry, I don't mean to be an idiot about all this. I think I understand the concept of LOCKING and UNLOCKING the tracks in the timeline. I'm just not getting the whole thing of PATCHING and UNPATCHING tracks, and when patching and unpatching is to be used instead of locking and unlocking. It's a mental block of some sort??
    Thanks,
    Jeff
    Message was edited by: jla930

  • User Decision - locking an object

    Hello,
    I'm using User decision step to send workitem to approver for travel request approval. If the travel request is already locked then user should get standard error when clicked on Approve/Reject buttons and the workitem should remain in the approver's inbox for approval. Please advice me in this.
    Thanks in Advance.
    Siva Sankar.

    Hi
    Please elaborate on your requirement as to why such a behaviour is required.
    Also by locking do you mean that the trip has status locked or it is the concept of locking you are talking about.
    Thanks and Regadrs
    Aman
    Edited by: AmanGupta on Apr 13, 2010 1:42 PM

  • How to LOCK a table in SAP?

    Hi,
    Just wondering is there a way we can lock a table in SAP?
    tcode or something?
    ex. there a tcode to lock tcodes (SM01)
    so wondering if there is a tcode or another method?
    Thanks!

    Hi,
    These are application locks not the database tables lock.
    If you use this function modules (enqeue and dequeue)
    then only it works the concept of locking.If you dont use this fms then you can directly access the table.
    If I am the developer and I dont implement the  locks then no locking concept would happen.
    Regards,
    Vamshi.

  • How to implement locking in ABAP

    Hello everyone,
        I am doing dialog programming and I have a screen that creates some template. When the user opens up the screen it defualts to next available template number to be created (for example if template No 1 exists then it will default to template no 2 so template 2 will be created). But if multiple users open up the screen then it will show template 2 for both of them and I want to avoid this, i.e. I like to implement some locking mechanism so one user opens up the screen that template is locked and the other cannot create the same template. Please share any ideas and suggestions, how I can imeplement this!
    Thanks.
    Mithun

    Hai  Mithun Dha
    Lock Objects
    The R/3 System synchronizes simultaneous access of several users to the same data records with a lock mechanism. When interactive transactions are programmed, locks are set and released by calling function modules (see Function Modules for Lock Requests). These function modules are automatically generated from the definition of lock objects in the ABAP Dictionary.
    Structure of a Lock Object
    The tables in which data records should be locked with a lock request are defined in a lock object together with their key fields. When tables are selected, one table (the primary table) is first selected. Further tables (secondary tables) can also be added using foreign key relationships (see also Conditions for Foreign Keys).
    Lock Arguments
    The lock argument of a table in the lock object consists of the key fields of the table.
    The lock argument fields of a lock object are used as input parameters in the function modules for setting and removing locks generated from the lock object definition. When these function modules are called, the table rows to be locked or unlocked are specified by defining certain values in these fields. These values can also be generic. The lock argument fields therefore define which subset of the table rows should be locked.
    The simplest case of a lock object consists of exactly one table and the lock argument of the table is the primary key of this table. Several tables can also be included in a lock object. A lock request therefore can lock an entire logical object, and not only a record of a table. Such a logical object can be for example a document comprising an entry in a header table and N entries in a position table.
    Locks can also be set from programs in other systems with the corresponding interfaces if the lock object was defined with RFC authorization.
    A lock mode can be assigned for each table in the lock object. This mode defines how other users can access a locked record of the table.
    Table SFLIGHT in the  flight model contains all the scheduled flights of a carrier. Field SEATSMAX contains the number of seats available. Field SEATSOCC contains the number of seats already booked. If a booking is made for a customer (by a travel agency or sales desk), you must check whether there are enough seats available. The number of seats booked is incremented when the booking is made.
    This mechanism must ensure that two sales desks do not make the same booking at the same time and that the flight is not overbooked.
    This can be done by creating lock object ESFLIGHT. Only the table SFLIGHT must be included in this lock object. The flight can then be locked (with the function modules generated from the lock object) when booking. If another sales desk also wants to book seats for this flight, the lock will prevent the flight from being overbooked.
    Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
    The generated function modules are automatically assigned to function groups. You should not change these function modules and their assignment to function groups since the function modules are generated again each time the lock object is activated.
    Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.
    Parameters of the Function Modules
    Field Names of the Lock Object
    The keys to be locked must be passed here.
    A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
    Parameters for Passing Locks to the Update Program
    A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case a parameter must check that the lock has been removed.
    Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
    _SCOPE = 1: Locks and lock releases are not passed to the update program. The lock is removed when the transaction is ended.
    _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
    _SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
    Parameters for Lock Mode
    A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. Valid values for this parameter are S (shared), E (exclusive) and X (exclusive but not cumulative).
    The lock mode specified when the lock object for the table is created is the default value for this parameter. This default value can however be overridden as required when the function module is called.
    If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
    Controlling Lock Transmission
    Parameter _COLLECT controls whether the lock request or lock release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values:
    Initial value: The lock request or lock release is sent directly to the lock server.
    X : The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
    Behavior for Lock Conflicts (ENQUEUE only)
    The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
    You have the following options:
    Initial value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
    X : If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
    Controlling Deletion of the Lock Entry (DEQUEUE only)
    The DEQUEUE function module also has the parameter _SYNCHRON.
    If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.
    Exceptions of the ENQUEUE Function Module
    FOREIGN_LOCK: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
    SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
    If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
    Reference Fields for RFC-Enabled Lock Objects
    The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
    Parameters
    Reference fields
    X_<field name>
    DDENQ_LIKE-XPARFLAG
    _WAIT
    DDENQ_LIKE-WAITFLAG
    _SCOPE
    DDENQ_LIKE-SCOPE
    _SYNCHRON
    DDENQ_LIKE-SYNCHRON
    All the tables that can be included in a lock object must be linked with  foreign keys. There are a number of restrictions to the valid relationships.
    The foreign key relationships of the tables of the lock object must form a tree. The tables are the nodes of the tree. The links of the tree mean is the check table of.
    The foreign key fields must be key fields of the foreign key table.
    The foreign key relationships defined between the base tables of the lock objects may not have any field that is checked against more than one other field. A field therefore may not occur twice as foreign key field in a relationship and may not be checked against two different fields in two different foreign key relationships.
    You must keep one restriction in mind for  multi-structured foreign keys. If a field is assigned to a field that is outside the check table, the table containing this field must be in a sub-tree that contains the check table of this foreign key relationship as a root.
    These conditions are always satisfied if the key of the foreign key table is an extension of the key of the check table.
    Conditions 2, 3 and 4 are meaningless if the particular foreign key field was excluded from the assignment to the key fields of the check table by  marking it as generic or setting it to a constant. This is also true for multi-structured foreign keys if the foreign key field refers to a table that is not contained in the lock object.
    Regards.
    Eshwar.

  • Re: lock objects

    Hi,
         Iam implementing some screens. I created some lock objects. I could not able to  under these concepts. Even though I studied some documents, i could not get the below concepts. can anybody explain.
    1. what is the enqueue mode
    2. what is the scope
    3.what is the wait parametrs
    rgds
    p.kp

    Hi paluri,
    Info taken from standard sap help.
    1. Enqueu Mode.
    The lock mode controls whether several users can access data records at the same time. The lock mode can be assigned separately for each table in the lock object. When the lock is set, the corresponding lock entry is stored in the lock table of the system for each table.
    Access by more than one user can be synchronized in the following ways:
    Exclusive lock: The locked data can only be displayed or edited by a single user. A request for another exclusive lock or for a shared lock is rejected.
    Shared lock: More than one user can access the locked data at the same time in display mode. A request for another shared lock is accepted, even if it comes from another user. An exclusive lock is rejected.
    Exclusive but not cumulative: Exclusive locks can be requested several times from the same transaction and are processed successively. In contrast, exclusive but not cumulative locks can be called only once from the same transaction. All other lock requests are rejected.
    2. Scope
    Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
    _SCOPE = 1: Locks and lock releases are not passed to the update program. The lock is removed when the transaction is ended.
    _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
    _SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
    3. WAIT
    The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
    You have the following options:
    Initial value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
    X : If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
    regards,
    amit m.

  • Locked record in infotype 0167

    Hi,
    I would be thankful if some one can explain me the concept of lock record of an employee in infotype 0167.
    As in one of my requirement i have to fetch both the records ie active and locked (having same begda and endda).
    Is there any specific thing i need to do apart from
    INITIALIZATION.
    pnp-sw-ignorelockedrecords = 'N'.
    Regards
    Manu

    Hi Manu,
    Locked record means taht record id not yet ready to process / use in reporting, becuase that data is insuffient. You can lock/unlock a infotype record using pA30-0167-edit-Lock/Unlock option.
    For example infotype 2001 or 2002.
    Regards,
    Ranjith

  • Lock keyboard while running script

    Hello,
    Please let me know the concept to lock the keyboard while running the script to avoid any intervention by the users.
    Thanks,
    Praveen

    While the script is running, if it is properly written, the user should not be able to interfere with the workings of the script. as a extra measure, try using a scriptUI palette with a progress bar (see peter's book on the subject).
    Are you using stuff like "app.copy()" and app.paste()? That it is usually a recipe for disaster, and the one reason people ask about locking the keyboard.

  • Lock box functionality

    Can  lockbox functionality in SAP be used for  country Australia or the lockbox can only be implemented for the US country.Will each payment method(ex:checks,credit cards,ach) for each of them should have a different locbox.Will creditcards have a lockbox or is it just a separate file to be asked from bank based on the payment method we want.
    Thanks.

    Hi
    If bank provides the lock box facility in your country you can apply for the facility. This is not only for US. Lock box facility is given by bank for the receivables of company and not for the outgoing payments. The payees can drop the check in the lock box provided for your company at bank. This will reduce the time for encashment of check amounts. Credit card means you have to pay the amount to bank which is issued the credit card. So it will not come into lock box concept.  I think now you clear about the concept of lock box. Reward me if you satisfied with my answer.

  • How to unlock a system lock in a different context?!?

    Hi All,
    I want to unlock a system lock for an object in order_adm_h from a different context and I'm not sure if this could work at all (due to security settings)!
    If I use the function module "DEQUEUE_ECRM_ORDERADM_H" with the correct guid ithe unlocking doesn't work, which is probably because I'm in a different context.
    The main question is this: If I put a system lock (for a table, service ticket etc.) in one program, bsp application or whatever is it possible to unlock the system lock in a different application? If it is possible what do I need to do to unlock my service ticket?!?
    Of course I could use transaction code sm12, but this is not what i want to do (for multiple reasons).
    Thanks for helping,
    Rainer

    Hi,
    I am not sure whether there is any way to do it but, to me it looks like it is against the basic concept of locking.
    Regards,
    Bharat.

  • Implementing lock object

    I've a TCode to modify a report. That TCode picks a doc no. from a table & opens up an editable ALV based on that doc. no .That doc. no. is the only primary key.
    I want that if someone is already opened that report, & if someoen else is trying to open that report, it shouldn't open & should show that -"its locked by User  XXX". I've made a lock object for that table. Please advise what to do next. How to populate the User name who has locked the report.

    used ENQUEUE function  and DEQUEUE function
    Function Modules for Lock Requests
    Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
    The generated function modules are automatically assigned to function groups. You should not change these function modules and their assignment to function groups since the function modules are generated again each time the lock object is activated.
    Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.
    Parameters of the Function Modules
    Field Names of the Lock Object
    The keys to be locked must be passed here.
    A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
    Parameters for Passing Locks to the Update Program
    A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case, a parameter must check that the lock has been removed.
    Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
    &#65399;        _SCOPE = 1: Locks or lock releases are not passed to the update program. The lock is removed when the transaction is ended.
    &#65399;        _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
    &#65399;        _SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
    Parameters for Lock Mode
    A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. The values allowed for this parameter are S (read lock), E (write lock), X (extended write lock), and O (optimistic lock).
    The lock mode specified when the lock object for the table is created is the default value for this parameter. This default value can, however, be overridden as required when the function module is called.
    If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
    Controlling Lock Transmission
    Parameter _COLLECT controls whether the lock request or lock release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values:
    &#65399;        Initial Value: The lock request or lock release is sent directly to the lock server.
    &#65399;        X: The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
    Whenever you have lock mode X (extended write lock), locks should not be written to the local lock container if very many locks refer to the same lock table. In this case, there will be a considerable loss in performance in comparison with direct transmission of locks.
    Behavior for Lock Conflicts (ENQUEUE only)
    The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
    You have the following options:
    &#65399;        Initial Value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
    &#65399;        X: If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
    Controlling Deletion of the Lock Entry (DEQUEUE only)
    The DEQUEUE function module also has the parameter _SYNCHRON.
    If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.
    Exceptions of the ENQUEUE Function Module
    &#65399;        FOREIGN_LOCK’: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
    &#65399;        SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
    If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
    Reference Fields for RFC-Enabled Lock Objects
    The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
    Parameters
    Reference fields
    X_<field name>
    DDENQ_LIKE-XPARFLAG
    _WAIT
    DDENQ_LIKE-WAITFLAG
    _SCOPE
    DDENQ_LIKE-SCOPE
    _SYNCHRON
    DDENQ_LIKE-SYNCHRON
    See also:
    Example for Lock Objects
    http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eebf446011d189700000e8322d00/content.htm

Maybe you are looking for