-----------------------------2007-08-02~2007-08-06-------------------------------

 

-----------------------------2007-08-02~2007-08-06-------------------------------

1.      用

UPDATE <dbtab> [CLIENT SPECIFIED] FROM <wa>.

或者

UPDATE <dbtab> [CLIENT SPECIFIED].

更新数据库表的时候,要注意主键一定要写完整,而且即使有相同主键的情况上面的语句也只会更新第一条符合条件的记录

 

2.      确定可水平滚动的区域的左边界      SET LEFT SCROLL-BOUNDARY [COLUMN <col>].

3. Programming Transactions

Transactions

A transaction is a logical process in the R/3 System. Examples include generating a list of customers, changing a customer's address or booking a flight reservation for a customer. From the user's point of view, it is a self-contained unit.

Caution: As in DP generally, the term "transaction" has several different meanings in the R/3 System:

o        In terms of database programming, a transaction - also known as a database transaction or an LUW - is an inseparable sequence of database operations concluded with a database commit.

o        In terms of dialog programming, a transaction - also known as an SAP transaction (see CALL TRANSACTION) - is a complex object which consists of a module pool and screens, and is called with a transaction code. An SAP transaction usually covers a whole series of logical processes. For example, the SAP transaction SE38 allows you to display, change, print or rename ABAP/4 programs.

Update transactions

Preserving database integrity

If a transaction involves updating the database, the changes are made either in their entirety or not at all (see example under "Semantic integrity" in Database Integrity). The successful conclusion of a transaction is concluded by a database commit, but an error triggers a database rollback (see LUW). Since database updates in one LUW cannot be canceled by a database rollback in a subsequent LUW, all database updates in one transaction must be performed in a single LUW.

To achieve this, each transaction should contain a single database commit. With many transactions, there are three reasons to contradict this point of view:

o        Duration of database locks

To protect a database object against accesses by other transactions, it is locked by the database system until the next database commit (see Database Locking). If this lock is retained for more than one dialog step, the system would then wait for further user input. The uncontrolled duration of this database lock would thus adversely affect the parallel execution of several transactions. For this reason, each dialog step in the R/3 System is concluded by a database commit. A transaction containing more than one dialog step contains more than one LUW .

o        Overflow of the rollback log

To be able to perform a database rollback, a database system must generate a copy of each database object before making a change. These copies are kept in a rollback log until the end of an LUW . An overflow of the rollback log always results in the termination of the transaction which caused it. For example, attempting to remind a large number of defaulting customers in the same transaction could trigger such an error. You can onls solve this problem by dividing the set of database updates into several smaller units ( LUW s) for the database system. In this particular example, the executing program could perform a database commit for each customer reminded.

o        Exceeding the time allocation

Bundling database updates

In the interests of data integrity, all the database updates for transactions which contain more than one LUW should be bundled together into one single LUW . To prevent overload here, you can delay the execution of FORM routines and functions in ABAP/4 programs.

o        PERFORM form ON COMMIT

By using the addition ON COMMIT , you can delay execution of a subroutine until the next ABAP/4 command COMMIT WORK occurs. All subroutines specified in this way are executed together in the LUW concluded by this COMMIT WORK

o        CALL FUNCTION function IN UPDATE TASK

With this statement, the function module function is registered so that it can be executed by an update process on encountering the next ABAP/4 command COMMIT WORK . In this case (i.e. asynchronous processing), the dialog process does not wait until the function module has been executed. However, with COMMIT WORK AND WAIT (i.e. synchronous processing), the processing does not continue until the function module has finished. All function modules specified as "Update with immediate start" or "Immediate start, no restart" (in short V1 ) are executed together in one LUW. All function modules specified as "Update with delayed start (in short V2 are executed in a separate LUW. The type V2 is mainly used for less urgent database updates (e.g. of a statistical nature).

o        CALL FUNCTION function IN BACKGROUND TASK

With this statement, the function module function is registered so that it can be executed on encountering the next ABAP/4 command COMMIT WORK . In this case (i.e. asynchronous processing), the dialog process does not wait until the function module has been executed. All function modules specified in this way are executed together in one LUW by any dialog process.

By using the addition DESTINATION , you can even run the function module in a different R/3 System (see Transactional Remote Function Call). In this case, all function modules specified in this way for one destination executed together in one LUW.

This technique of bundling database updates allows you to distribute the execution of a transaction across several work processes and even across different R/3 Systems.

The ABAP/4 commands COMMIT WORK and ROLLBACK WORK

When using the bundling technique, you must always signal the conclusion of an update transaction by calling the ABAP/4 command COMMIT WORK once . In addition to the database commit, this triggers all the FORM routines and functions registered by this transaction. While the database commit simply leaves a Logical Unit of Work ( LUW ) after successful conclusion, the ABAP/4 command COMMIT WORK only triggers part of the processing within a transaction. A transaction cannot be considered as successfully completed until this part has also been successfully executed.

Although it is not obligatory, you should signal the conclusion of an update transaction that uses the bundling technique by calling the ABAP/4 command COMMIT WORK. This is not only good programming style, but also relieves you from having to release locked objects explicitly (see SAP Locking).

If an error is detected during the transaction, you can use the ABAP/4 command ROLLBACK WORK to roll back the database to its level before the beginning of the transaction.

Handling terminations

If the processing of parts of a transaction is delayed, runtime errors may occur. In this case, you should be aware of the following:

If a runtime error occurs or if you call the ABAP/4 command MESSAGE with the message type 'A' in a FORM routine form registered with PERFORM form ON COMMIT, the LUW that contains the ABAP/4 command COMMIT WORK is automatically canceled by a database rollback (see LUW). Then, no further registered FORM routines or functions are executed and the user sees the relevant information about the termination on the screen. The ABAP/4 command ROLLBACK WORK results in a runtime error.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a V1 function function registered with CALL FUNCTION function IN UPDATE TASK , all database updates of already executed V1 functions are automatically canceled by a database rollback (see LUW). V2 functions and functions registered with CALL FUNCTION IN BACKGROUND TASK are not executed. All database updates of the LUW that contain the ABAP/4 command COMMIT WORK and thus all updates of FORM routines registered with PERFORM ON COMMIT are not canceled.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a V2 function function registered with CALL FUNCTION function IN UPDATE TASK, only the database updates of this V2 function are automatically canceled by a database rollback (see LUW). Any existing V2 functions and functions registered with CALL FUNCTION IN BACKGROUND TASK are executed.

With V1 and V2 functions, the user sees information about the termination on the screen, provided his/her R/3 System has been set up accordingly. By choosing Tools -> Administration -> Monitoring -> Update, he/she can analyze the termination and - after eliminating the cause of the termination - manually restart all functions of the type 'Update with immediate start' and 'Update with delayed start' that belong to the transaction.

If a runtime error occurs or if you call the ABAP/4 command ROLLBACK WORK or MESSAGE with the message type 'A' in a function function registered with CALL FUNCTION function IN BACKGROUND TASK, all the database updates of already executed functions of the same destination are automatically canceled by a database rollback (see LUW). The user sees information about the termination on the screen. If an error is detected during the processing of a function registered in this way, you can decide in the program whether all the functions with the same destination should be executed again after the database rollback (see Transactional Remote Function Call).

Short response times in dialog transactions

The acceptance of dialogs by users depends entirely on transaction response times. In this context, success rests not only on the short response times of a user's "own" transaction. Since the response times of one transaction affects those of another, you must always take response times of other transactions into account when programming. By their nature, database operations contribute most to the increase of response times in dialog transactions.

Distributing a transaction across several work processes

By bundling database updates, you can distribute a transaction across several work processes. Asynchronous execution of the database update in an update or background process shortens response times in the dialog process.

Schematic flow of a transaction:

d p1 b1 d f1 g p2 d f2 b2 d c t1   d   w
| LUW1  | LUW2    |  ...  | LUWn   |        | LUW ...
|-------|---------|-------|--------|--------|---dialog process-->

                                    d  t2   d     d t3  d
                                    |  LUW  | ... | LUW |
----------update process------------|-------|-----|-----|----->

                                              d t4  d
                                              | LUW |
----------dialog process----------------------|-----|--------->

b1 , b2 ,,Registration of functions for execution in the background
c ,,,,ABAP/4 command COMMIT WORK
d ,,,,Database commit
f1 , f2 ,,Registration of V1 functions for execution in update process
g ,,,,Registration of V2 functions for execution in update process
p1 , p2 ,,Registration of FORM routines
t1 ,,,,Execution of all registered FORM routines
t2 ,,,,Execution of all registered V1 functions
t3 ,,,,Execution of one registered V2 function per LUW
t4 ,,,,Execution of all registered functions in the background
w ,,,,Wait until all V1 functions have finished in case of
,,,, COMMIT WORK AND WAIT

For further information please refer to

SAP Transaction Concept

 

4.      SAP Locking

Create lock object:

Se11-------- 〉定义 lock object , 一般用 以 e 开头名字------>然后选择要锁的table,和mode------->...---->完成后系统就会生成RFC以供调用. ENQUEUE_obj 是 lock 用的 , DEQUEUE_obj 是 unlock 用的 .

To synchronize simultaneous access by several users to the same data, the R/3 System provides a further locking mechanism in addition to database locking.

A write lock is set by the value 'E' and a read lock by the value 'S' .

You use the parameter _WAIT to determine behavior in the event of such a collision.

Normally, each lock is released at the end of the SAP transaction without calling the corresponding DEQUEUE function module. However, this does not apply if the transaction has called update routines (see Programming Transactions). In this case, you can handle locks with the _SCOPE parameter. The values of this parameter have the following meaning:

相关T-Code:SM12-----------查看当前锁

database LUW (Logical Unit of Work)

 Caution: The SAP locking mechanism sets logical locks. In contrast to database locking, a transaction does not lock concrete objects, but describes those objects it wants to lock with a condition.

就是说 , SAP locking 在锁住相应的 DBTable 后仍然可以对该表直接用 update 语句 . SAP locking 应该是在应用层的锁机制 . 该锁会在使用它的那段程序结束的时候自动被解开 , 当然 , 也可以用 DEQUEUE_obj 手动解锁

Database LUW vs. SAP LUW

In the case of the database, an LUW is a sequence of data operations that cannot be divided up. The operations are either carried out in full or not at all. Database LUWs are modules that make up the database procedures for consistent data processing.

By way of contrast, an LUW for the SAP System is a business process, which cannot be divided up. The process is either executed in full or not at all. An SAP LUW usually must include several database LUWs (see graphic above), each of which can be terminated with a database COMMIT, which is generated automatically.Under normal circumstances, the SAP LUW contains a dialog part (which maps a business process), and the command for writing the data to the database (update part).