What you should do and not do where locking is concerned...
- Do Use the locking mechanism when changing table records (change = create, update and/or delete)
- Don't Create a new lock object or use an alternative one if one is already set up for the logical unit of work you want to address.
- Do Look for (and always find) the lock objects SAP is using for their tables, if you need to direclty update a SAP table
- Don't Assume that not using the locking mechanism will lead to a reliable system: you know better!
- Do Make sure your own program can run several times at the same time - or protect your program from allowing this (via locking)
- DON'T IGNORE THE SUBJECT OF LOCKING!
Bold statements
- (It is assumed that) No standard SAP R/3 table update is done without locking
- Even if locking is forgotten about in an ABAP development, locking is still done on a database level, making sure database updates can be performed. This is very reliable locking, but no update should be done without locking described in these articles
- Locking a table does not stop physical changes to tables: a table update can still be done even when locked by another user (try this!)