hi all update

[Former Member]

hi all

what is v1 and v2 updates and what is their significance.

also, how does local update work, does it continue to upload records after getting error record or not.

thanx in advance

rocky

[Former Member]

Hi rocky,

V1 and V2 Update Modules

An update is divided into different modules (see also Update Request). Each module corresponds to an update function module.

There are two types of module.

The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2) update modules. The system also supports collective runs for function modules that are used on a regular basis.

This distinction allows the system to process critical database changes before less critical changes.

V1 modules describe critical or primary changes; these affect objects that have a controlling function in the SAP System, for example order creation or changes to material stock.

V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such as result calculations.

The V1 modules are processed consecutively in a single update work process on the same application server. This means that they belong to the same database LUW and can be reversed. Furthermore, V1 updates are carried out under the SAP locks of the transaction that creates the update (see The SAP Lock Concept). This ensures that the data remains consistent; simultaneous changes to the objects to be updated are not possible.

All V2 updates are carried out in a separate LUW and not under the locks of the transaction that creates them. If your SAP System contains a work process for V2 updates, these are only carried out in this work process. If this is not the case, the V2 components are processed by a V1 update process.

All V1 modules of an update must be processed before the V2 modules.

Let us assume that a transaction makes planning changes to a material and balance sheet, and updates two sets of statistics.

Each of these changes is represented by means of an update module (call update function module) in the update request - the two planning changes by a V1 update module (time critical), and the statistical changes by a V2 update module (less critical). (The V1 modules have priority, although the V2 modules are usually also processed straight away).

This is described in greater detail in the section entitled The Update Process.

The Update Process

Purpose

Among other things, the update system is used to lighten the workload of the SAP transactions when time-consuming changes are made to the database. The changes are carried out asynchronously - usually with short delays in between - by special update work processes.

This is why the update system is widely used in SAP transactions (by almost every transaction that changes business data), although transactions can also change the data directly in the database.

Prerequisites

The application programmer decides whether, and if so, how, the update system is used for developing transactions. The different options open to the programmer are described in detail in the ABAP manual in the section entitled Update Techniques.

When you are working with the SAP update system, it is important to make sure that only insert, update and delete statements are executed in the update. The necessary data should, of course, be gathered together beforehand (using select and so on). Programming that has not been carefully thought through can result in poor system performance, and can, in certain cases, cause serious problems.

Process Flow

As illustrated in the graphic in Functional Description of Updates, at the end of a transaction COMMIT WORK and the update task are called; the dialog part of the SAP transaction is closed, and the update part of the SAP logical unit of work (LUW) is started. The following graphic illustrates the necessary actions and the sequence in which they execute the different work processes.

Update Techniques

The main update technique for bundling database changes in a single database LUW is to use CALL FUNCTION... IN UPDATE TASK. This section describes various ways of updating the database.

A program can send an update request using COMMIT WORK

To the update work process, where it is processed asynchronously. The program does not wait for the work process to finish the update ( Asynchronous Update).

For asynchronous processing in two steps ( Updating Asynchronously in Steps.)

To the update work process, where it is processed synchronously. The program waits for the work process to finish the update ( Synchronous Update).

To its own work process locally. In this case, of course, the program has to wait until the update is finished ( Local Update

thanks

karthik

reward me if usefull

[Former Member]

Hi Rocky,

V1 - Synchronous update

V2 - Asynchronous update

V3 - Batch asynchronous update

These are different work processes on the application server that takes the update LUW (which may have various DB manipulation SQLs) from the running program and execute it. These are separated to optimize transaction processing capabilities.

Taking an example -

If you create/change a purchase order (me21n/me22n), when you press 'SAVE' and see a success message (PO.... changed..), the update to underlying tables EKKO/EKPO has happened (before you saw the message). This update was executed in the V1 work process.

There are some statistics collecting tables in the system which can capture data for reporting. For example, LIS table S012 stores purchasing data (it is the same data as EKKO/EKPO stored redundantly, but in a different structure to optimize reporting). Now, these tables are updated with the txn you just posted, in a V2 process. Depending on system load, this may happen a few seconds later (after you saw the success message). You can see V1/V2/V3 queues in SM12 or SM13.

V3 is specifically for BW extraction. The update LUW for these is sent to V3 but is not executed immediately. You have to schedule a job (eg in LBWE definitions) to process these. This is again to optimize performance.

V2 and V3 are separated from V1 as these are not as realtime critical (updating statistical data). If all these updates were put together in one LUW, system performance (concurrency, locking etc) would be impacted.

Serialized V3 update is called after V2 has happened (this is how the code running these updates is written) so if you have both V2 and V3 updates from a txn, if V2 fails or is waiting, V3 will not happen yet.

[vinod_vemuru2]

Hi Rocky,

Not sure of V1 & V2 updates. I think they are based on priority.

Local update: Seperate update process will not be created as in case of synchronous and asynchronous updates. The process which is doing the work of executing ur program will do the updation work also. In case od synch and asynch process a separate work process will be created(Called as Update work process) which will only does database updation work. Another work process will do the execution work.

Thanks,

Vinod.