Full Repair/Init/Delta & LO Cockpit Information required

I'm pretty new to BW and I'm starting to dig a bit more now into the deeper stuff now.  I've created Cubes with Extractor from R/3 and now I'm interested to understand more the LO Cockpit various specificities.
For a better understanding, let's establish a scenario as --> Activation of R/3 SD Billing --> BW --> DSO --> Info Cube
Ok, first, let me start by explaining what my understanding is.
First, I need to go into R/3, t-code LBWE, and under the "13: SD Billing BW", activate the extractors I'm interested in (Header & Item as an example in my scenario).  I'm also assuming that the default fields within the extractors are suiting my needs so no adjustments needed for now.  I should also schedule a job here that will create records in the Waiting Queue on a daily basis.
Next, I need to fill the setup tables from the t-code SBIW; I enter a date in the future, it runs for a while, then I get my data prepared.  In the setup table, it included all the existing R/3 invoices as of now right? (1)  Let's say there are new invoices created minutes after I've created the setup table, they will be sent to the Waiting Queue as soon as the document are created or will the schedule job created earlier will post them to that Queue? (2)  If the job send them to the Waiting Queue, where are sitting the pending documents before being sent then? (3)
Now, on my BW system, once the Data Source have been replicated, what do I need to create and execute to be able to proceed with a Delta process? (4) I know I have to create a u201CInitu201D package 1st but have no clue why except that itu2019s needed for me to be able to create a u201CDeltau201D  package afterwards.  Technically, what does the u201CInitu201D package really does? (5)  What is the reason to have a u201CInit without datau201D and u201CInit with datau201D, I mean, I know literally what it means but again, why would I choose one over the other? (6)
Iu2019d also like to understand the concept behind a "Full Repair" request, which I have no clue what the purpose is.  I guess there some of these properties (Full Repair, Init) determines where to get the data on the R/3 side; Setup Tables or Waiting Queue? (7)
Please, provide clear respond (Donu2019t assume I know what youu2019re think of ) on my questions (identified by a bold number) and don't hesitate to provide a long one if needed to; it's better to provide more information than not enough
Thank you in advance for all of your help!
P.s. I'm working with BI 7.0.

So if I understand properly, whenever I run the init, it toggle a flag on my source system (R/3) which means that all changes performed in the invoices are going to be sent in the Delta Queue? Until I run an Init, changes are not written anywhere (Other than internal SAP tables/structures required by R/3 Invoices processes).
If so, does this means that I could loose some transactions from the time I run the creation of the setup tables and the time I execute the Init on my BW system? Let's say I create the setup table today and execute the init only tomorrow; all invoices that have been created by this time won't be tranferred to BW?
yes,suppose you create a set up table today....and ron the init tomorrow........in between many new recordsmay come.......but those new records will not be in the set up table.......since those transaction happenned after the filling of the set up table........and new records only goes to Delta queue after you run the init.......
I have to admit that it's hard for me to "Suppose" i did not want to do an init; what would be a good reason not to? I understand that both Init types will toggle the "Init" flag on but still can't figure appropriate business scenarios for both types
Suppose your Delta mechanism is corrupted.......for which you need to do a full repair......I mean first ,you have to delete the existing init flag.........second, you will fill the set up table .......third,you will load the records by Full repair......then 4th step will be running init without data transfer..only to set the init flag..........it will not pick any records.............then delta.......
Init with data transfer picks all the previous records......we cannot give any selection..............for selection we have to use Full repair.........then init without data transfer..............generally for Transaction data we will go for Full repair..........bcoz otherwise number of recordswill be very huge........and there may be duplicate records..................
Another thing we want to say........we do full repair we mainly use for ODS.........it is just like Full upload.........in case of infocube we can use full upload instead of full repair.........but in case of ODS full repair is must............since ODS does'nt support Full upload and Delta upload parallely........otehrwise ODS activation will fail........
Then again you hav to use the Program : RSSM_SET_REPAIR_FULL_FLAG  to convert full upload request to full repair request.....
Hope this helps....
Edited by: Debjani  Mukherjee on Nov 7, 2008 10:45 PM

Similar Messages

  • Full repair or Delta Init?

    Hi Experts
    I need your suggest
    Sometime we need made a re-load one month, and Im using a 'full repair'; but this give me errors (duplicate or missing records) where users are working in R/3 at the same time.  Other posibilite is a 'full load' + 'delta init with out records'.   Which is better in this case? 
    b) People say than after use a 'full load' you lose the init flag and is necessary made a init again.
    In this case a made a 'full load' for 001.2008, and 'full repair' for 002.2008; and the init flag / delta load seemed ok. Is this possible? 
    c) When use a 'full repair', (with selection scope = 001.2008), how does it work?  read from R/3 again or repeat the delta loads for the month specified in the selection, in the infopackage?
    Thank you in advance!!

    Pls see these links
    data extraction via combination of full + init updates
    How to load init -delta requests when full load already exist
    Full Upload and Init Delta Load

  • Init & Delta After Full Load

    hii Experts
    I have one doubt please clarify that.
    If i have a Cube and i m pulling data on basis of Full Load . Then i switch to delta load, before that i took the INIT load without data transfer.
    But after a couple of days i need to pull the full load again for that particular period, for that i delete the INIT request & also the Delta request from Cube & PSA. & after full load i want to pull the delta load.
    Now my doubt is how does this process impact on loading process?Is the previous init & delta also have some impact on the current delta loading???
    Thanks in Advance

    There is absolutely no problem in doing a full loaf after init delta.
    doing full load doesnt disturb the delta status.
    Here i explain how an init and delta works
    Init and Delta :
    Once you are done with fetching all data from source using fullload, you have to run init.
    all the new records that appear in the source system after init will sit in the delta queue.
    when ever you run delta after the init, all the new records will coime to Bi and once this delta runs succesfully, these records will be cleared from the queue in source system and the new records from then comes to the queue.
    this way, we can be sure that there is no loss of data.
    Full load after delta :
    now comming to your answer, if you run a full load, the data is not fetched from the delta queue and it doesnt disturb the queue in any way. it only brings all the data from soure(according to selection condition). so the delta is not disturbed in any way.
    Repair Full  Request :
    The repair full request acts in the same way as full load in fetching data from source.
    the only difference is in updating the target.
    Rather than updating the data in the request, it checks out for the changes in already loaded data and update if there are any changes (Repairing the data already loaded.
    That means there is no impact of previous init without data transfer in the current delta loading?
    If you go thru the above explanation you can get this answer easily.
    Init is used to set the delta pointer due to which the present delta is working fine.
    Hope this answer helps you,
    Thanks and Regards,

  • Generic Delta: Init, Full Upload and Deltas...

    Dear All,
    Last week on 10.04.2014 I've created "Generic DataSource with Generic Delta" and used CalDay as Delta-Specific Field and lower limit kept to blank and upper limit to 1. On 11.04.2014 I've initialized the Delta with Data Transfer using Process Chain: Time 1:15 p.m (Note: Posting was on)
    see below screen shot:
    Result: Process Chain was scheduled to immediate and it executed and initialized the delta and brought records as well. See below screen shot of RSA7:
    Q: 1: Why generic delta current status is 10.04.2014, as I'v scheduled delta through process chain on 11.04.2014 @ 20:50: and why Total column is showing 0 records? Even I've checked Display Data Entries with Delta Repetition, but could not find any records?
    Following is the InfoPackages which I created for Delta Loads and used in another Process Chain for Delta scheduled (daily @ 20: 50).
    Following is the DTP used into Delta Process Chain:
    On 12/04/2014 when I checked my InfoCube, and found that same number of records being loaded again despite InfoPackage and DTP were created as Delta, see screen shot:
    On 12/04/2014 See below PSA table:
    On 14/04/2014 when I checked InfoCube and I saw deltas being loaded successfully: see below screen shot:
    On 14/04/2014 see below PSA table:
    On 14/04/2014 see below RSA7 BW Delta Queue Maintenance screen shot:
    Q: 2: Why am I unable to load the Delta records on the day(11/04/2014) when I initialized it with Data and why same number of records being loaded again on 11/04/2014?
    Q: 3: On 11/04/2014, around 1:15 p.m I've initialized Delta with Data successfully and the same day (11/04/2014) was my first load of delta records (Time: 20: 50), could this be a problem? as the posting period was on when I initialized and I tried to load the delta on the same day?
    Q: 4: Why the pointer is showing me Current Status: 12/04/2014 today and this time around I can find last delta records from "Display Data" option with Delta Repetition?
    Q: 5: Have I missed something in the design or data flow?
    Q: 6: How can I verify deltas records accuracy on daily basis; is it from RSA3?
    or How can I verify daily deltas with ECC delta records?
    Q: 7: What is the best practice when you load full data and initialized delta and schedule deltas for Generic DataSources with CalDay as delta specific field?
    I will appreciate your replies.
    Many Thanks!!!
    Tariq Ashraf

    I clearly got ur point.....But
               If i have situation like ....." I loaded the LO data from R/3 with Init delta......then i loaded 5 loads of delta too.......due to some error in data now i am trying to load all th data......In this case if i do Full upload it is going to bring all the data till 5 th delta load .......If i do Init delta again it is going to bring the same data as full upload..........In LO while loading both Full load or delta init load we need to lock R/3 users....I believe we can load delta even after full upload by using "Init delta without data transfer"............So that wont be the barrier....then what is the difference or how should i figure out which load should i do.............If i am wrong please correct me.......

  • Delta Load is not pulling any data....Need to Run Full Repair EVERYTIME ? ?

    Dear Experts,
    Today again I need your help gurus.
    The Delta load is running everyday but its not getting any data to BW form CRM. But when the User raises an issue regarding the data , I pull the data by Repair Full load by some Selection ( Same selection of Delta + Transaction No ).
    The selection(For Full Repair Load ) is only the Transaction No and the Sales Organization.
    The selection for the normal Delta is Sales Organization ( 0CRM_SALORG ) 50000609.
    But I am confused about the issue.
    Kindly put some light on this issueu2026

    Hi Sanjana:
       Have you applied any SAP Note to fix this problem? Please check if the SAP Note below helps you in solving this issue.
    Note 788172 - "CRM BW adapter: No data in delta with parallel processing"
    Francisco Milán.

  • ODS optioin- Is it going to be full upload or init delta?

    Hi frnds,
               I got a query where the scenerio goes like this,
    Data loading from ods to infocube. Let us suppose in ods settings, i have selected the option Update data targets from ODS object automatically. Then my question is whether it will be a init delta or full upload.....please explain the scenerio.
    thanks in advance

    Hi Vinit,
    This will be dependent to the load in ODS,
    if the load is init in ods the further upload will be init.
    If the load to ods is delta the further upload will be delta
    Reward if useful

  • Init Delta for 0FIGL_O06 required?

    Quick question for everyone.
    I need to delete and re-load data in 0FIGL_O06 due to some missing deltas (which are no longer avail in PSA).  If I look back at the requests in the ODS now (done by my predecessor) I don't see an INIT delta...just delta loads starting several months ago.
    <b>If I need to delete and reload do I first need to run an INIT DELTA load?</b>

    Hi Barnaby,
    I guess there are so many requests that you are not able to see the Init request in the display. Change the display selection criteria and see if you can see the Init request. The delta requests can not run without init request. Hope this helps.
    Thanks and Regards
    Subray Hegde

  • A full repair request

    Hello Gurus,
         what is a full repair request?
    Many thanks,

    Hai ,
    Q. Repair Full Request
    Ans: You can find the option in the InfoPackage. Open up the InfoPackage and press ShiftCtrlF1 or from the menu Scheduler > Repair Full request. You need to check in the box and it will be done.
    You can go in for a repair full request when you have missed any delta loads or there are data corruption issues. By doing a full repair load, you can ensure that your data is correct and has good integrity.
    With this option you can continue to use your existing delta and not worry about resetting the delta.
    But make sure that the ODS is in overwrite mode and not additive. If its additive then you will face the problem of having duplicate data. If this is the case then you have to delete all the contents and then do the full repair request.
    Say if your current scenario has init/delta setup to your ODS.
    And for some reason you have to do a full load because you missed some data or you have to load some historic data.
    Then if you do a full load to ODS then the request will be loaded but do not get activated as full load to ODS once the delta/ init is setup.
    So in these scenarios you'll have to go for repair full request option when loading to ODS.
    You'll have the same option when loading to CUBE but in cube it doesn't matter as it is possible to do a full load even we had delta/init.
    So doing repair full will not disturb your Delta mechanism in your ODS.
    OSS Note on Repair Full Request.
    Some data is incorrect or missing in the PSA table or in the ODS object (Enterprise Data Warehouse layer).
    There may be a number of reasons for this problem: Errors in the relevant application, errors in the user exit, errors in the DeltaQueue, handling errors in the customers posting procedure (for example, a change in the extract structure during production operation if the DeltaQueue was not yet empty; postings before the Delta Init was completed, and so on), extractor errors, unplanned system terminations in BW and in R/3, and so on.
    Read this note in full BEFORE you start actions that may repair your data in BW. Contact SAP Support for help with troubleshooting before you start to repair data.
    BW offers you the option of a full upload in the form of a repair request (as of BW 3.0B). If you want to use this function, we recommend that you use the ODS object layer.
    Note that you should only use this procedure if you have a small number of incorrect or missing records. Otherwise, we always recommend a reinitialization (possibly after a previous selective deletion, followed by a restriction of the Delta-Init selection to exclude areas that were not changed in the meantime).
    1. Repair request: Definition
    If you flag a request as a repair request with full update as the update mode, it can be updated to all data targets, even if these already contain data from delta initialization runs for this DataSource/source system combination. This means that a repair request can be updated into all ODS objects at any time without a check being performed. The system supports loading by repair request into an ODS object without a check being performed for overlapping data or for the sequence of the requests. This action may therefore result in duplicate data and must thus be prepared very carefully.
    The repair request (of the "Full Upload" type) can be loaded into the same ODS object in which the 'normal' delta requests run. You will find this request under the "Repair Request" option in the InfoPackage (Maintenance) menu.
    2. Prerequisites for using the "Repair Request" function
    2.1. Troubleshooting
    Before you start the repair action, you should carry out a thorough analysis of the possible cause of the error to make sure that the error cannot recur when you execute the repair action. For example, if a key figure has already been updated incorrectly in the OLTP system, it will not change after a reload into BW. Use transaction RSA3 (Extractor Checker) in the source system for help with troubleshooting. Another possible source of the problem may be your user exit. To ensure that the user exit is correct, first load a user exit with a Probe-Full request into the PSA table and check whether the data is correct. If it is not correct: Search for the error in the exit user. If you do not find it, we recommend that you deactivate the user exit for testing purposes and request a new Full Upload. It If the data arrives correctly, it is highly probable that the error is indeed in the user exit.
    We always recommend that you load the data into the PSA table in the first step and check the result there.
    2.2. Analyze the effects on the downstream targets
    Before you start the Repair request into the ODS object, make sure that the incorrect data records are selectively deleted from the ODS object. However, before you decide on selective deletion, you should read the Info Help for the "Selective Deletion" function, which you can access by pressing the extra button on the relevant dialog box. The activation queue and the ChangeLog remain unchanged during the selective deletion of the data from the ODS object, which means that the incorrect data is still in the change log afterwards. After the selective deletion, you therefore must not reconstruct the ODS object if it is reconstructed from the ChangeLog. (Reconstruction is usually from the PSA table but, if the data source is the ODS object itself, the ODS object is reconstructed from its ChangeLog). You MUST read the recommendations and warnings about this (press the "Info" button).
    You MUST also take into account the fact that the delta for the downstream data targets is created from the changelog. If you perform selective deletion and then reload data into the deleted area, this may result in data inconsistencies in the downstream data targets.
    If you only use MOVE and do not use ADD for updates in the ODS object, selective deletion may not be required in some cases (for example, if incorrect records only have to be changed, rather than deleted). In this case, the DataMart delta also remains intact.
    2.3. Analysis of the selections
    You must be very precise when you perform selective deletion: Some applications do not provide the option of selecting individual documents for the load process. Therefore, you must first ensure that you can load the same range of documents into BW as you would delete from the ODS object. This note provides some application-specific recommendations to help you "repair" the incorrect data records.
    If you updated the data from the ODS object into the InfoCube, you can also delete it there using the "Selective deletion" function. However, if it is compressed at document level there and deletion is no longer possible, you must delete the InfoCube content and fill the data in the ODS object again after repair.
    You can only perform this action after a thorough analysis of all effects of selective data deletion. We naturally recommend that you test this first in the test system.
    The procedure generally applies for all SAP applications/extractors. The application determines the selections. For example, if you cannot use the document number for selection but you can select documents for an entire period, then you are forced to delete and then update documents for the entire period in the data target. Therefore, it is important to look first at the selections in the InfoPackage exactly before you delete data from the data target.
    Some applications have additional special features:
    Logistics cockpit: As preparation for the repair request, delete the SetUp table (if you have not already done so) and fill it selectively with concrete document numbers (or other possible groups of documents determined by the selection). Execute the Repair request.
    Caution: You can currently use the transactions that fill SetUp tables with reconstruction data to select individual documents or entire ranges of documents (at present, it is not possible to select several individual documents if they are not numbered in sequence).
    FI: The Repair request for the Full Upload is not required here. The following efficient alternatives are provided: In the FI area, you can select documents that must be reloaded into BW again, make a small change to them (for example, insert a period into the assignment text) and save them -> as a result, the document is placed in the delta queue again and the previously loaded document under the same number in the BW ODS object is overwritten. FI also has an option for sending the documents selectively from the OLTP system to the BW system using correction programs (see note 616331).
    3. Repair request execution
    How do you proceed if you want to load a repair request into the data target? Go to the maintenance screen of the InfoPackage (Scheduler), set the type of data upload to "Full", and select the "Scheduler" option in the menu -> Full Request Repair -> Flag request as repair request -> Confirm. Update the data into the PSA and then check that it is correct. If the data is correct, continue to update into the data targets."
    Another Scenario where we use Repair Full Request
    If your data load is delta and now if you are planning to run Full load, then you can go for Repair full request.
    Eg: If you have missed data for 3 days and next delta loads are running successfully, in this case if you want to fill data for only particular 3 days, than you can run the statistical setup for that particular data source for 3 days and load it as a full load through repair request.
    It is particularly used in the upload of data into the ODS ,if the ODS has already Delta loads.
    This is required if want to upload any full uploads(with selection at infopackage or without) to be done to ODS, because ODS does not allow to activate the simple Full uploads if there are delta loads to it.
    But make sure that check the option "indicate request as repair" in the Scheduler before you start the IP.
    Kiran Manyam

  • Change from Full load to delta load.

    Hi Gurus,
    I have one ODS object which is extracting data from r/3 system.this ODS object is getting loaded on a daily basis,& it's having heavy volume data (takes almost 8 hours to load).
    Now I want to change the load mode of that ODS from FULL load to Delta Load
    How can I do that ?
    I tried to do* Init without data transfer* from source to this ODS obejct , but while activation it's saying Full load is already loaded so no init
    I want to change the load mode of that ODS object without deleting the data,as it takes lot of time to load the total data.
    Is there any way to that??
    Plz help.Thanks in advance.
    Kironmoy Banerjee.

    1 more question,if run that function module,will it change the existing loads in Repair full mode?
    or it will load the total data again.
    If you run RSSM_SET_REPAIR_FULL_FLAG Program and give ODS name etc.. it will turn all Full loads to Repair full mode.
    1. Run that function module.
    2. give ODS,data source name.
    3 it will change the existing load to repair full load,
    4.Init without data transfer. (i am not sure if this step is required or not.)
    5.delta load.

  • Regarding full repair

    Hello All,
    I have a situation here, is as follows,
    I did init without data transfer for a perticular sale organization now I want to do full repair for that sale org from R3 (LIS_13_VAITM).
    My question is do I need to fill setup table for full repair or not required.
    Please reply ASAP.

    Hi Patil,
    U have to fill setup table for missing sales org.
    before that delete existing data in setup table.
    After filling setup table,Run full update with repair.
    Vijay sekhar reddy.

  • Unable to create Init Delta InfoPackage.

    Hi Experts,
    I am working on BI 7.0 within Solution Manager (GSB 100).
    Since I am extracting data from only 2 tables into 2 different InfoCubes, we did not require to create any Master Data loads.
    In order to load these 2 InfoCubes, I have created 2 Transactional Generic DataSources in RSO2. When I try to create an InfoPackage from the context menu of these DataSources, Only Full Update is coming up in the Update Tab.
    I'll create 2 Process Chains eventually for each InfoCubes. How can I create one Init Delta with / without Data Transfer and another Delta InfoPackage?
    Any help is very much appreciated. Points will be assigned.

    Hi Naveen,
    You were right. I changed it to Generic Delta and it's working fine now.
    Thanks a lot for that. Points assigned.
    Quick one... If I wanted to do a Delta Load each time except for the very first time (i.e. Init Delta), it better to have 2 InfoPackages. But should they be as below:
    1. Init Delta (should this be With Data or Without Data Transfer...?)
    2. Delta Update

  • Duplicate Records in Infocube : Full Repair without DSO is possible ?

    Hello Gurus,
    I have a critical situation in BI production. we have more then 3 years of data in inventory infocubes (PSA->ODS->CUBE). everything was working fine till december 2010. after that in January 2010 and March -2010 we were getting double records in infocubes. in this scenarion we don't have ODS in between.
    The solution which i find is delete all data from Jan -2010 till today in infocube and also from PSA. on R/3 side delete set up tables and fill setup tables for Jan-2010 to Mar-2010. and create a infopackage for Full Repair request .  but i have below questions for these solution
    (1) For Full Repair Info Package or Full Repair Request we don't need to delete INIT request .. correct me if i am wrong.
    (2) For full repair request do we need to run Initialize Delta With Out Data Transfer first and then we have to do Full Repair ?
    (3) If we don't have DSO in these scenario then also can we solve this with full repair request ?
    Komik Shah

    Hi Venu,
    We have data in PSA since 13/04/2010 because the process chain was failing since last 15 days. so  didn't get new records in PSA also. we are using BI 7.0.
    Whole scenario is like this.
    Data is there in Inventory Cube since last 3 year. but no body monitor the process chain since last 15 days and no body analyze any reports after dec-09. now they Analyze the report in April-10 and for some months they are getting Double records. process chain was  failing since last 15 days and the reason behind that was  INDEXING as well as wrong records in PSA.
    So, My plan was to delete data from Jan-2010 to April-2010 and fill setup tables between Jan-2010 to april.2010. i will get data into PSA. but when i will load data to cube. i will get double records whether it's a full repair or not .
    Komik Shah
    Edited by: komik shah on Apr 30, 2010 12:38 PM

  • INIT Delta

    can anybody tell me how to delete init delta? Is it like full delta..delete a request in mange of the cube?

    Hi Hyma,
    Go to R3 rsa7 transaction and also idelete the r3 queue. In BW  delete all the data from the Infocube and all the Init.
    Now redo all from the start.
    Look at this post...
    Automatic deletion of previous init loads in process chains
    If you are sure that no one has put another data in the source system then you can use the existing set up table and do a fresh init.
    But the data you have deleted from the delta queue will get lost beacuse they are niether in the set up table nor in the delta queue and it will not get picked at any cost.even if you do a full repair.
    If you would have pulled delta then you could have used the set up table.
    SO you will have to again fill the set up table so that you have deleted delta records now in set up table and then load from it.
    Just do a fresh init without data transfer.
    Fill the set up table.
    then run a full repair request
    and then schedule a daily delta load
    every thing will work fine
    Hope This Helps.
    ****Assign Points If Helpful****

  • Problem when running Init Delta

    Hi Friends,
               I'm trying to run Init delta , There is already a Full update run on this ODS , Now since I'm running an Init Delta on this , I'm getting an error that Full Update is already been run on this.
    What is the solution for this?? From now I want to do Init delta and Delta on this , Since the number of records are increasing.
    Please advice,

    Hi !
    In the scheduler , select repair full request.
    Give a try
    I am not sure , about this

  • Update ST/PI Plugin - Init delta queue

    Hi guys,
    Yesterday, our basis team, asked me to clean all extraction queue in BW. They will update a plugin (ST/PI) that control the connection between the enviroment BWP and ECP.
    I have to delete all the queues in transactions SMQ1, RSA7 and empty the setup table using LBWG. The note 1081287 will give a better explanation about this.
    My question is:
    Will I have to restart all the LIS extraction again with full update?
    For example, to start the datasource 2LIS_08TRTLP, I have to execute the transaction VTBW and after execute an init delta in BW with all data.
    Is there a way to start this delta without carry all the data again?
    I wanna carry only the new data to BW to update the cubes

    Hello Ralf,
    They asked me to do these steps:
    1 - Call transaction SMQ1 and check whether all queues in all clients (client = '', queue name 'MCEX') have been processed. To process the queues, start the collective run report for each application in the displayed clients. If you no longer need the data in the BW system, deactivate the relevant extraction queues and DataSource in the LO cockpit (transaction LBWE) and delete the queue entries in transaction SMQ1.
    2 - Before the upgrade, delete the contents of the setup tables. Execute report RMCEX_SETUP_ENTRIES to find out which setup tables still contain entries. You can use transaction LBWG to delete the contents of the setup tables for all clients.
    If I delete the contents of the setup tables using LBWG transaction, Will I have to restart all the queues again? Will I lost data?
    Thank you

Maybe you are looking for