Skip to Content
author's profile photo Former Member
Former Member

V3 V2 V1

Dear Experts in BW,

I hope to be enlightened on a few aspects of LO extraction mechanism. I have read the wonderful weblogs & found it excellent for understanding the subject.

However, I still have a couple of queries. Pls help with as many of them as u can. I am preparing for exams.

1. What is technically different about Update Tables (V3 Update) vs Delta Queue (Direct Delta) vs Extraction Queue (Queued Delta)? Are they simply normal tables? Why the different names? Sounds as if they are different technically.

2. Is V3 update a variant type of update process similar to V1 & V2, the ones u see in traditional R/3? V3 is new technology right? I have used R/3 for many years and never heard of V3 update until BW. But this V3 we are talking about is in R/3. So, I don't understand V3. Is it differentiated by the 'urgency' of the record being updated?

3. Why is it that V2 update is said to be problematic? How come V1 update is not as problematic (failed updates)?

4. For V3 Update using V3 Collective run, how is it different technically than an Extraction Collective run (Queued Delta)? Does it mean that Extraction collect uses V1?

5. How is reading Update Tables to a module (V3) different from reading Extraction Queue to an Application (Queued Delta)? Application also uses a module right? So, why the different names?



Message was edited by: bworbust

Add a comment
10|10000 characters needed characters exceeded

Related questions

1 Answer

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Feb 18, 2005 at 02:32 PM

    Hi bworbust,

    sorry if I'm concise, but now I really don't have a minute...


    Update tables contain the data to be changed until it is written to the database in a database LUW:

    VBHDR - update headers

    VBMOD - update modules

    VBDATA - update data

    VBERROR - error information

    Delta queue is a data store in the source system into which data records are automatically written using an update process in the source system (such as with FI documents) or using extraction using a function module after a data request from the BW (such as LIS extraction prior to BW 2.0).

    With a delta request, the data records are transferred from the Scheduler into BW.

    The data is stored in compressed form in the delta queue. It can be requested from several BW systems. The delta queue is also repeat enabled. In other words, the delta queue stores data from the last extraction process.

    With the queued delta, the extraction data is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.

    For an overview of the structure of extraction queues use transaction LBWQ or via the "Log queue overview" function in LBWE.


    V3 collective update must be scheduled as a job (this is the main difference from V1 and V2 and this last one asynchronous as V3 but with no scheduling possibility)...however, please refer to the first weblog episode for pro and cons...


    V2 is problematic only for serialized V3 (see the second weblog episode)...

    V1 is problematic too (but this is a general transaction related problem since no apllication tables would be updated in this case...)


    As in V3, you have to use the same collective run job, but data are stored in (and extracted from) different tables!


    Different delta places, different names, different involved extraction module ! see a picture in the third weblog episode



    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      Dear Roberto,

      You are truely excellent in explaining the detail concepts of BW.

      Would u comment on what are the 3 tables forming the Delta Queue mentioned in BW350 pg4-9? Its mentioned in book but not specified what they are.

      Thank you very much, Roberto!



      Message was edited by: bworbust to specify the page he was referring to.

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.