Missing Delta LO

Hi
     We had some problems in R/3 and failed all the Application 11 jobs last month (about 7days). We have fixed that problem and made a full load of that week using the field ERDAT (Created on)...But we lose the changes for those 7 days. Now when i check the extractor for those changes...I cant see the changed on data for those 7days..Can any one let me know How can I get those 7days changes with the changed on data (AEDAT)...

Hello Sam,
Its better to do a full load with Sales Document Number and other paramerters like Sales Org etc and not with AEDAT as AEDAT is not a part of the Selection.
Goto the base tables and give the ERDAT for that period and get the sales Document number, then use that in the Full Load and extract the data. Make sure that you mark the full load Infopackage with repair request if you have delta.
Thanks
Chandran

Similar Messages

  • Missing Delta Records for 2LIS_02_ITM & SCL

    Hi Experts,
    this is how my problem goes.
    i have done my set up table filled on 12th Dec 2010 and from that time onwards the delta were running everyday and filling the DSO and Cube.
    Accidently by some others PC in prod all my delta loads and the setup table load is being deleted except yesterday in PSA for these 2 extractors and now because of some change i have to do a full load to DSO.
    But as the PSA is emply and have only yesterday's request i have, deleted that one as well and done a Init Delta to it and i found out that only the Set up table is comming now and all the deltas in between are missing.
    i have tried a full LOAd to PSA and the result is same.
    How can i get those missing delta records from 12th Dec last year till today with out doing another set up table fill  or Do i have to have fill the set up table again till today and thats the only way? i will set the delta again after that.
    Do we have to have all the user locked for the setup table fill (for Queued Delta type) ? Lot of people says yes you have to and others says no you don't require. i got one white paper and it clearly says no user locking is required. please find the link below. what is the correct way?
    [http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d019f683-eac1-2b10-40a6-cfe48796a4ca?quicklink=index&overridelayout=true]

    Hi,
    As per my knowledge you want load particular period of data try repair request may issue solve.
    Regards
    Sivaraju

  • WARNING - Attempting to resync due to missed delta reports (sp return code = 7)

    Hello,
    I have investigated and found out that there are more than 150 machines which are not reporting their H/W inventory.
    When checking on some of the machines, there are following entries in dataldr.log
    Processing Inventory for Machine: ABC   Version 44.2  Generated: 12/05/2014 11:42:15
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    Begin transaction: Machine=ABC(GUID:############)
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    WARNING - Attempting to resync due to missed delta reports (sp return code = 7)
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    Rollback transaction: Machine=ABC(GUID:#############)
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    SQL MESSAGE: spAddInventoryLog - Inventory Log for machine:ABC,Server:1.10,Client:44.2,Message:Missing Delta. Resync,Detail:
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    Remote client hardware inventory resync generated for client GUID:#############; update/insert result = 1
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    Send resync command to local site for machine GUID:#############.
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    STATMSG: ID=2722 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=<primary server> SITE=SiteCode PID=19068 TID=15432 GMTDATE=Fri Dec 05 10:43:09.184 2014 ISTR0="ABC" ISTR1="" ISTR2=""
    ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)
    Cannot process MIF XHAOPNXZQ.MIF, moving it to C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\DeltaMismatch\1ub4cajr.MIF
    SMS_INVENTORY_DATA_LOADER 12/5/2014 4:13:09 PM
    15432 (0x3C48)

    Hey Garth,
    I have forced the full inventory already but here are the results.
    Inventoryagent.log - Before the full inventory
    Inventory: *********************** Start of message processing. ***********************
    InventoryAgent 12/6/2014 6:23:14 PM
    5776 (0x1690)
    Inventory: Message type is InventoryAction InventoryAgent
    12/6/2014 6:23:15 PM 5776 (0x1690)
    Inventory: Temp directory = C:\Windows\CCM\Inventory\Temp\
    InventoryAgent 12/6/2014 6:23:15 PM
    5776 (0x1690)
    Inventory: Clearing old collected files. InventoryAgent
    12/6/2014 6:23:15 PM 5776 (0x1690)
    Inventory: Opening store for action {00000000-0000-0000-0000-000000000001} ...
    InventoryAgent 12/6/2014 6:23:15 PM
    5776 (0x1690)
    Inventory: Action=Hardware, ReportType=Delta, MajorVersion=48, MinorVersion=1
    InventoryAgent 12/6/2014 6:24:09 PM
    5776 (0x1690)
    Inventory: Initialization completed in 54.553 seconds
    InventoryAgent 12/6/2014 6:24:09 PM
    5776 (0x1690)
    Inventoryagent.log - Full Inventory
    Inventory: *********************** Start of message processing. ***********************
    InventoryAgent 12/6/2014 6:31:11 PM
    5668 (0x1624)
    Inventory: Message type is InventoryAction InventoryAgent
    12/6/2014 6:31:11 PM 5668 (0x1624)
    Inventory: Temp directory = C:\Windows\CCM\Inventory\Temp\
    InventoryAgent 12/6/2014 6:31:11 PM
    5668 (0x1624)
    Inventory: Clearing old collected files. InventoryAgent
    12/6/2014 6:31:11 PM 5668 (0x1624)
    Inventory: Opening store for action {00000000-0000-0000-0000-000000000001} ...
    InventoryAgent 12/6/2014 6:31:11 PM
    5668 (0x1624)
    CInvState::VerifyInventoryVersionNumber: Mismatch found for '{00000000-0000-0000-0000-000000000001}': 48.1 vs. 0.0
    InventoryAgent 12/6/2014 6:32:05 PM
    5668 (0x1624)
    Inventory: Version number mismatch; will do a Full report.
    InventoryAgent 12/6/2014 6:32:05 PM
    5668 (0x1624)
    Inventory: Action=Hardware, ReportType=ReSync, MajorVersion=49, MinorVersion=0
    InventoryAgent 12/6/2014 6:32:05 PM
    5668 (0x1624)
    Inventory: Initialization completed in 53.212 seconds
    InventoryAgent 12/6/2014 6:32:05 PM
    5668 (0x1624)
    *+*+*++*+*+*+
    *+*+*+*+*+*+
    Collection: 57/69 inventory data items successfully inventoried.
    InventoryAgent 12/6/2014 6:32:29 PM
    6596 (0x19C4)
    Inventory: Collection Task completed in 23.993 seconds
    InventoryAgent 12/6/2014 6:32:29 PM
    6596 (0x19C4)
    Inventory: 12 Collection Task(s) failed. InventoryAgent
    12/6/2014 6:32:29 PM 6596 (0x19C4)
    Inventory: Temp report = C:\Windows\CCM\Inventory\Temp\d3d81696-58c0-4313-a108-258996a0a75f.xml
    InventoryAgent 12/6/2014 6:32:29 PM
    6596 (0x19C4)
    dataldr.log
    *** [22001][8152][Microsoft][SQL Server Native Client 11.0][SQL Server]String or binary data would be truncated. : pINSTALLED_SOFTWARE_DATA
    SMS_INVENTORY_DATA_LOADER 12/6/2014 3:03:16 PM
    11696 (0x2DB0)
    ERROR - SQL Error in SMS_INVENTORY_DATA_LOADER
    12/6/2014 3:03:16 PM 11696 (0x2DB0)
    ERROR - is NOT retyrable. SMS_INVENTORY_DATA_LOADER
    12/6/2014 3:03:16 PM 11696 (0x2DB0)
    Rollback transaction: Machine=ABC(GUID:EE4DB508-7271-4568-9A6D-0C4A64569AE4)
    SMS_INVENTORY_DATA_LOADER 12/6/2014 3:03:16 PM
    11696 (0x2DB0)
    Cannot process MIF XHFR7KJDQ.MIF, moving it to C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\ErrorCode_4\hnue114o.MIF
    SMS_INVENTORY_DATA_LOADER 12/6/2014 3:03:16 PM
    11696 (0x2DB0)
    STATMSG: ID=2703 SEV=W LEV=M SOURCE="SMS Server" COMP="SMS_INVENTORY_DATA_LOADER" SYS=PRIMARY SERVER SITE=SITECODE PID=12272 TID=11696 GMTDATE=Sat Dec 06 09:33:16.513 2014 ISTR0="XHFR7KJDQ.MIF" ISTR1="C:\Program Files\Microsoft
    Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\ErrorCode_4\hnue114o.MIF" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0
    SMS_INVENTORY_DATA_LOADER 12/6/2014 3:03:16 PM
    11696 (0x2DB0)
    The error here is C:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\ErrorCode_4, but it is different for other machines where i tried the full inventory.

  • Missing delta

    We have upgraded our BW 3.x to BW 7, this is how we performed it:
    1) We copy/export the existing BW into a  new machine
    2) Perform the upgrade from 3.x to BW 7 on this new machine in 10 days
    3) Now want to connect the ECC6 to this new machine and go life.
    Question:
    a) When we copy the existing BW into the new machine, we have all the latest data copied also. But how can we load those delta (10 days) into this new machine?
    b)  Also, how can we switch the ECC6 to this new machine?

    Sven,
    yes, I think we're not on the same page
    Let me explain the background:
    1) We have copy the Production BW (BW 3.5) into a new server.
    2) We then upgrade the new server from BW 3.5 to BW 7. We spent 10 days for this. During these 10 days, data loading still happened in the Production BW (BW 3.5).
    3) Now, we're planning to do the cut-over and I was wondering how can we reload the last 10 days data into the new BW 7? This data include also Delta from LO Cockpit.
    4) Since the Delta has been loaded into Production BW, based on your following, I dont understand how we can do it because there is nothing we can load in RSA7 (Delta)?
    1.. you can load the data in 7.0 - because there are missing data.
    2. stop the load in 3.x
    3. create a "init without data" in 7.0
    => do step 2 and 3 in a time where nobody is on the system and change data
    4. load the last delta to 3.x (start the infopackage several times)
    5. copy the data from 3.x to 7.0 system.
    => now you have the missing delta in 7.0
    6. now you can start the delta von 7.0 system
    Pleasea advise, thank you.
    Edited by: lynn on Feb 15, 2010 1:37 AM

  • Issue in tRFC - missed delta records

    Hi All,
    There was a load failure few days ago in BI and we can see entries in tRFC. Mistakenly the request status was set to green in BI and so subsequent loads completed successfully. Now we found that the records are missing in BI. When we try to execute LUWs in tRFC, it gives message in BI monitor screen "request that can not be processed since request properly ended".
    Is there a way that we can process the data in tRFC or re-extract data?
    Cheers,
    Sai

    HI,
    You can go for Full repair request .
    It wont affect your delta.
    Just run the Full infopasckage with Full repair request and give the selection criteria.
    Hope it is helpful.
    Thanks,
    Saveen Kumar

  • Missed Delta

    Dear Experts,
    We have daily DELTA  loads for stock data,
    but due to system configuration our BI server was down for 2 days tht is on saturday - sunday(25-26/7/09)
    but on monday support guy has missed to load the records for stock.
    is there any way to get those records in BI.
    Regards,
    Vivek Tripathi

    Hi Vivek,
    According to me, there will be no option to delete the contents of delta que in RSA7. THe delete option we see there,  is to delete the entire structure of the que, in your case that is not happend because monday data got extracted from delta que.
    1) may be data is extracted before monday and the request got deleted from the target. To confirm this, please check the infopackage load monitor details from saturday to monday. if you find any log which loaded data to target that means data came to BW but got deleted. this you can load again from PSA.
    2) As your doubt, data might be mistakenly delelted from queue, this might be done in the T code SMQ1.  in this case you can fill the setup tables by taking the material document numbers posted on 2 days from the application tables. ( i guess the number will be less) and Run a repair full load to BW.

  • Missing delta records for the Z extractor

    Hi,
    I have created a Z extractor for the table BUT050 in CRM. I have created a function module and have included the delta logic on CRDAT which is the created date, CRTIM - created time, CHDAT - change date, CHTIM - Change time. I have initialed the delta and started doing the delta loads. I found that there are few missing records in the extractor when compared to the table. I'm attaching my code below.Can anyone please look into it and tell me what the issue is.
    Text removed by moderator
    Thanks
    FUNCTION Z_BI_CC_BUT050.
    *"*"Local Interface:
    *"  IMPORTING
    *"     VALUE(I_REQUNR) TYPE  SRSC_S_IF_SIMPLE-REQUNR
    *"     VALUE(I_DSOURCE) TYPE  SRSC_S_IF_SIMPLE-DSOURCE OPTIONAL
    *"     VALUE(I_MAXSIZE) TYPE  SRSC_S_IF_SIMPLE-MAXSIZE OPTIONAL
    *"     VALUE(I_INITFLAG) TYPE  SRSC_S_IF_SIMPLE-INITFLAG OPTIONAL
    *"     VALUE(I_READ_ONLY) TYPE  SRSC_S_IF_SIMPLE-READONLY OPTIONAL
    *"     VALUE(I_REMOTE_CALL) TYPE  SBIWA_FLAG DEFAULT SBIWA_C_FLAG_OFF
    *"  TABLES
    *"      I_T_SELECT TYPE  SRSC_S_IF_SIMPLE-T_SELECT OPTIONAL
    *"      I_T_FIELDS TYPE  SRSC_S_IF_SIMPLE-T_FIELDS OPTIONAL
    *"      E_T_DATA STRUCTURE  ZBI_BUT050 OPTIONAL
    *"  EXCEPTIONS
    *"      NO_MORE_DATA
    *"      ERROR_PASSED_TO_MESS_HANDLER
    * Auxiliary Selection criteria structure
       DATA: l_s_select TYPE srsc_s_select.
    * Maximum number of lines for DB table
       STATICS: s_s_if TYPE srsc_s_if_simple,
    * counter
               s_counter_datapakid LIKE sy-tabix,
    * cursor
               s_cursor TYPE cursor.
    * Select ranges
       RANGES: l_r_RELNR FOR ZBI_BUT050-RELNR,
               l_r_PARTNER1 FOR ZBI_BUT050-PARTNER1,
               l_r_PARTNER2 FOR ZBI_BUT050-PARTNER2,
               l_r_DATE_TO FOR ZBI_BUT050-DATE_TO,
               l_r_ZZTMSTMP FOR ZBI_BUT050-ZZTMSTMP.
       DATA : startdate LIKE sy-datum,
              starttime LIKE sy-uzeit,
              enddate LIKE sy-datum,
              endtime LIKE sy-uzeit,
              tstamp LIKE tzonref-tstamps,
              timezone type TZONREF-TZONE.
       RANGES: l_r_CRDAT FOR ZBI_BUT050-CRDAT,
                       l_r_CRTIM FOR ZBI_BUT050-CRTIM.
    * Initialization mode (first call by SAPI) or data transfer mode
    * (following calls) ?
       IF i_initflag = sbiwa_c_flag_on.
    * Initialization: check input parameters
    *                 buffer input parameters
    *                 prepare data selection
    * Check DataSource validity
         CASE i_dsource.
           WHEN 'ZCC_MA_BUT050'.
           WHEN OTHERS.
             IF 1 = 2. MESSAGE e009(r3). ENDIF.
    * this is a typical log call. Please write every error message like this
             log_write 'E'                  "message type
                       'R3'                 "message class
                       '009'                "message number
                       i_dsource   "message variable 1
                       ' '.                 "message variable 2
             RAISE error_passed_to_mess_handler.
         ENDCASE.
         APPEND LINES OF i_t_select TO s_s_if-t_select.
    * Fill parameter buffer for data extraction calls
         s_s_if-requnr    = i_requnr.
         s_s_if-dsource = i_dsource.
         s_s_if-maxsize   = i_maxsize.
    * Fill field list table for an optimized select statement
    * (in case that there is no 1:1 relation between InfoSource fields
    * and database table fields this may be far from beeing trivial)
         APPEND LINES OF i_t_fields TO s_s_if-t_fields.
       ELSE.                 "Initialization mode or data extraction ?
    * Data transfer: First Call      OPEN CURSOR + FETCH
    *                Following Calls FETCH only
    * First data package -> OPEN CURSOR
         IF s_counter_datapakid = 0.
    * Fill range tables BW will only pass down simple selection criteria
    * of the type SIGN = 'I' and OPTION = 'EQ' or OPTION = 'BT'.
           LOOP AT s_s_if-t_select INTO l_s_select WHERE fieldnm = 'RELNR'.
             MOVE-CORRESPONDING l_s_select TO l_r_RELNR.
             APPEND l_r_RELNR.
           ENDLOOP.
          LOOP AT s_s_if-t_select INTO l_s_select WHERE fieldnm = 'PARTNER1'.
             MOVE-CORRESPONDING l_s_select TO l_r_PARTNER1.
             APPEND l_r_PARTNER1.
           ENDLOOP.
           LOOP AT s_s_if-t_select INTO l_s_select WHERE fieldnm = 'PARTNER2'.
             MOVE-CORRESPONDING l_s_select TO l_r_PARTNER2.
             APPEND l_r_PARTNER2.
           ENDLOOP.
           LOOP AT s_s_if-t_select INTO l_s_select WHERE fieldnm = 'DATE_TO'.
             MOVE-CORRESPONDING l_s_select TO l_r_DATE_TO.
             APPEND l_r_DATE_TO.
           ENDLOOP.
    * Timestamp is delivered as a selection criterion.
    * Split the timestamp into date and time
          LOOP AT s_s_if-t_select INTO l_s_select WHERE fieldnm = 'ZZTMSTMP'.
             tstamp = l_s_select-low.
             timezone = 'EST'.
             CONVERT TIME STAMP tstamp TIME ZONE timezone
              INTO DATE startdate TIME starttime.
             tstamp = l_s_select-high.
             CONVERT TIME STAMP tstamp TIME ZONE timezone
              INTO DATE enddate TIME endtime.
             l_r_CRDAT-low = startdate.
             l_r_CRDAT-sign = l_s_select-sign.
             l_r_CRDAT-option = l_s_select-option.
             l_r_CRDAT-high = enddate.
             APPEND l_r_CRDAT.
             l_r_CRTIM-low = starttime.
             l_r_CRTIM-sign = l_s_select-sign.
             l_r_CRTIM-option = l_s_select-option.
             l_r_CRTIM-high = endtime.
             APPEND l_r_CRTIM.
           ENDLOOP.
    * Determine number of database records to be read per FETCH statement
    * from input parameter I_MAXSIZE. If there is a one to one relation
    * between DataSource table lines and database entries, this is trivial.
    * In other cases, it may be impossible and some estimated value has to
    * be determined.
           OPEN CURSOR WITH HOLD s_cursor FOR
    * Use the l_r_erdat and l_r_erfzeit for both creation and change selections
    * This way we can pick up both the creations and changes in a given time period.
           SELECT * FROM BUT050
                  WHERE RELNR IN l_r_RELNR
                   AND PARTNER1 IN l_r_PARTNER1
                   AND PARTNER2 IN l_r_PARTNER2
                   AND DATE_TO IN l_r_DATE_TO
                   AND ( CRDAT >= startdate AND ( CRTIM >= starttime OR ( CRDAT <= enddate AND CRTIM <= endtime ) ) )
                   OR ( CHDAT >= startdate AND (  CHTIM >= starttime OR ( CHDAT <= enddate AND CHTIM <= endtime ) ) ).
         ENDIF.
         "First data package ?
    * Fetch records into interface table.
    *   named E_T_'Name of extract structure'.
         FETCH NEXT CURSOR s_cursor
                    APPENDING CORRESPONDING FIELDS
                    OF TABLE e_t_data
                    PACKAGE SIZE s_s_if-maxsize.
         IF sy-subrc <> 0.
           CLOSE CURSOR s_cursor.
           RAISE no_more_data.
         ENDIF.
         s_counter_datapakid = s_counter_datapakid + 1.
       ENDIF.              "Initialization mode or data extraction ?
    ENDFUNCTION.
    Message was edited by: Matthew Billingham

    Hi,
    As per my knowledge you want load particular period of data try repair request may issue solve.
    Regards
    Sivaraju

  • How to recover the missing delta records from R/3

    Hi Experts,
    I am Beginner in BI.
    User has created a ticket stating that, he found that there are only three invoice numbers pulled from R/3 (2lis_13_vaitm) to cube for date on 24.05.2010 where has in r/3 there are 372 invoice numbers are available.  
    i was suggested to recover the data for 24th may'10.
    Please tell me detailed steps to recover the data for one day. Invoice data source will feed the data to DSO and then CUBE.
    Thanks in Advance.
    Latha.

    Hi,
      Please search in forum for how to do a repair full load. You have to fill the setup tables for 24th of may and then do a repair full load.Also check is there any restriction which prevented the invoices from loading.
    Regards,
    Raghavendra.
    Edited by: Raghavendra Padmanaban on Sep 23, 2010 1:42 PM
    Edited by: Raghavendra Padmanaban on Sep 23, 2010 1:43 PM

  • Missing V2 records using Unserialized V3 deltas in Logistics

    We have been experiencing missing Deltas in our Material Movement transactions feeding BW. This always occurs between 5:30AM and 6:00AM. When we examine the intermediate queues we notice the Deltas are not present in the V2 queue. I have read several articles describing the process by which SAP moves Deltas through its arthitecture in order to get Deltas from ECC all the way to the Delta Queue in BW using the Unserialized V3 update method of extraction. All the articles state very clearly that if the V2 update fails, then the transactions are not going to make it through to the Delta queue - that makes sense.
    What none of the articles explain, and what doesn't make sense, is why the V2 updates would fail in the 1st place. So...that is my question - Under what circumstances would the system not complete a V2 update? As a result of messing around with this problem for a couple of weeks and not getting anywhere, we have abandoned the Unserialized V3 Delta process in favor of using the Direct Delta technique. The up side is we will be getting all the Deltas into BW. The down side is that we have not solved our problem - we've only circumvented it, and the next time we attempt to implement the Unserialized V3 update technique, we most likely will go through a similar period of frustration.
    I'm NOT looking for info on "where to look". I'm looking for "concepts" - whiy would a V2 udpate fail? If I know the answer to that question, then the answer to "where to look" should be obvious.
    Thanks in advance for someone's help.

    Hello,
    Here are some useful tips (in my opinion) to this problem:
    - Refer to transaction SM13 to view the 'V2' requests which aren't made into 'V3' Queue. Choose the status option 'V2 Executed', user as '*"  and select the appropriate time. This transaction would provide all the V2 requests which wern't updated. It's also possible to re-post the failed updates using the "Repeat update" option
    - Normally there will be a dump recorded to respective failed update and this can be check using the transaction ST22. If you analyze the problem then you might be able to find the root cause of this failure.
    We are using the 'Queued' delta method for application '03' and this method is working fine and never missed any documents. May be it's worth checking this update method.
    Hope the above tips will help you.
    Cheers
    Bala Koppuravuri

  • Delta issue on a Generic Datasource

    Hi
       I had a Generic Datasource on a Z table.
       The Z table had a Date field on which Delta is based.The Postings are performed manually.
      How to solve the delta issue in the below scenario.
    Ex; A user made a manual posting with a date 09AUG2010 today and delta is extracted to BW.
        But tommorow a used made another posting with a date 14JULY2010....
    Currently that record is not being extracted....how can i resolve this
    Thanks

    Hi,
    Once the data source is created you will extract the data till that date and as the delta is set it will fetch the newly updated records .But i dont think one can post with the back dates in R/3 side.
    If i'm not wrong if you are asking regarding record got missed out them wht need to be done?
    Then do the repair full request and pull the missed delta records and it wont effect the delta settings.
    Regards
    KP

  • Which is better or 'standard' option for a Delta DTP request

    Hi folks,
                I am creating a delta DTP for loading HR Payroll data. While creating the DTP I see two options
    a) Only Get Delta once
    b) Get all new data request by request
    which is a better option if I have a lot of records to upload for every delta upload.
    Points waiting to be given to you...
    Thanks
    Sunil

    U should go with Get all new data request by request
    i. With Only Get Delta Once, define if the source requests should be transferred only once.
    Setting this flag ensures that the content of the InfoProvider is an exact representation of the source data.
    A scenario of this type may be required if you always want an InfoProvider to contain the most recent data for a query, but technical reasons prevent the DataSource on which it is based from delivering a delta (new, changed or deleted data records). For this type of DataSource, the current data set for the required selection can only be transferred using a full update.
    In this case, a DataStore object cannot normally be used to determine the missing delta information (overwrite and create delta). If this is not logically possible because, for example, data is deleted in the source without delivering reverse records, you can set this flag and perform a snapshot scenario. Only the most recent request for this DataSource is retained in the InfoProvider. Earlier requests for the DataSource are deleted from the (target) InfoProvider before a new one is requested (this is done by a process in a process chain, for example). They are not transferred again by the DTP delta process. When the system determines the delta when a new DTP request is generated, these earlier (source) requests are considered to have been retrieved
    ii. Define if you want to Get All New Data in Source Request by Request.
    Since a DTP bundles all transfer-relevant requests from the source, it sometimes generates large requests. If you do not want to use a single DTP request to transfer the dataset from the source because the dataset is too large, you can set the Get All New Data in Source Request by Request flag. This specifies that you want the DTP to read only one request from the source at a time. Once processing is completed, the DTP request checks for further new requests in the source. If it finds any, it automatically creates an additional DTP request.
    u201COnly get Delta Onceu201D
    /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147only-get-delta-once148
    u201CGet Data by Requestu201D
    /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147get-data-by-request148

  • Repeating delta in Infospoke

    Hi,
    I have missed delta records in Infospoke. The first time 1850 records were uploaded to AL11. But before downloading the file, the Infospoke wa re-run again.
    The second time zero records were uploaded to AL11, over-writing the previous file.
    Is it possible to get back the delta records again???
    Kindly help. Points for sure!!!
    Thanks,
    Balaji V

    Hi
                I think it is posssible to get the delta records back with the request number,we have to search for that req in source system

  • Delta Compressed and Deleted in the stage before .

    Hi all,
    i have a critical issue with an Delta logic in one of my Cubes.
    A wrong ( logical ) Delta request was already Compressed in the Cube and Deleted in the stage before . This avoids further Delta Rquests in the Cube. By trying to request a delta i will be prompt to repeat the missing delta and it fails because of the missing request in the ODS. I cant reload the cube because of 14 Mio records this would take to long.
    anyone an Idea how to correct the delta flow without reloading everything?
    Many thanks in advance.
    Regards
    Ali

    see in rsa7 the content of the repeat, are you able to do a selective delete from your cube to remove only that data?
    If you can't manage that, you could set a repair request that fits the data you'll need to delete (date range? product? customer?) and only load the repair in the cube.
    To have the delta work fine again, set the original request to red and delete in the ODS as well and then run the repeat, you can't run the repeat as long as the request is in the ODS.

  • Reverse images in Pseudo delta

    Hi All,
    I have a generic extractor which fetches data from ECC based on pseudo delta.
    I am using type 0 in the date field to bring the delta records to BI.
    Problem.
    when I load a record to bw for example  a PO today and today the PO is deleted in ecc  and when I load the data tommorow to the bw, the record needs to get deleted from DSO and CUBE.
    To identify this I have a field 'deletion indicator' which i mapped to 0strno info object in the DSO.
    Reverse images are identified by the indicator 'R' but deletion indicator is marked as 'L'.
    How will the system identify the reverse image in this case?
    Please le me know the solution for this.
    Points assured.
    Regards
    Joga

    Ian, after looking at what SAP suggested 'Get Delta Only Once,' this should work for your scenario:
    Indicator: Only Get Delta Once
    Source requests of a DTP for which this indicator is set are only transferred once, even if the DTP request is deleted in the target.
    Use
    If this indicator is set for a delta DTP, a snapshot scenario is built.
    A scenario of this type may be required if you always want an InfoProvider to contain the most up-to-date dataset for a query but the DataSource on which it is based cannot deliver a delta (new, changed or deleted data records) for technical reasons. For this type of DataSource, the current dataset for the required selection can only be transferred using a 'full update'.
    In this case, a DataStore object cannot usually be used to determine the missing delta information (overwrite and creation of delta). If this is not logically possible because, for example, data is deleted in the source without delivering reverse records, you can set this indicator and perform a snapshot scenario. Only the most up-to-date request for the DataSource is retained in the InfoProvider. Earlier requests for the DataSource are deleted from the (target) InfoProvider before a new one is requested (this is done by a process in a process chain, for example). They are not transferred again during the DTP delta process. When the system determines the delta when a new DTP is generated, these earlier (source) requests are seen as 'already fetched'.
    Setting this indicator ensures that the content of the InfoProvider is an exact representation of the source data.
    Dependencies
    Requests that need to be fetched appear with this indicator in the where-used list of the PSA request, even is they have been deleted. Instead of a traffic light you have a delete indicator.
    -Alex

  • Delta get once and delta request wise?

    hi friends,
    what scenerio we use delta get once and delta by request at DTP in BI 7.0? i studied many threads, i didnt understand , get delta once some snapshot like? what is the meaning?
    can u give me any example , its great?
    regards
    ss

    Indicator: Only Get Delta Once
    Source requests of a DTP for which this indicator is set are only transferred once, even if the DTP request is deleted in the target.
    Use
    If this indicator is set for a delta DTP, a snapshot scenario is built.
    A scenario of this type may be required if you always want an InfoProvider to contain the most up-to-date dataset for a query but the DataSource on which it is based cannot deliver a delta (new, changed or deleted data records) for technical reasons. For this type of DataSource, the current dataset for the required selection can only be transferred using a 'full update'.
    In this case, a DataStore object cannot usually be used to determine the missing delta information (overwrite and creation of delta). If this is not logically possible because, for example, data is deleted in the source without delivering reverse records, you can set this indicator and perform a snapshot scenario. Only the most up-to-date request for the DataSource is retained in the InfoProvider. Earlier requests for the DataSource are deleted from the (target) InfoProvider before a new one is requested (this is done by a process in a process chain, for example). They are not transferred again during the DTP delta process. When the system determines the delta when a new DTP is generated, these earlier (source) requests are seen as 'already fetched'.
    Setting this indicator ensures that the content of the InfoProvider is an exact representation of the source data.
    Dependencies
    Requests that need to be fetched appear with this indicator in the where-used list of the PSA request, even is they have been deleted. Instead of a traffic light you have a delete indicator.
    Get Data by Request
    This indicator belongs to a DTP that gets data from a DataSource or InfoPackage in delta mode.
    Use
    If you set this indicator, a DTP request only gets data from an individual request in the source.
    This is necessary, for example, if the dataset in the source is too large to be transferred to the target in a single request.
    Dependencies
    If you set this indicator, note that there is a risk of a backlog: If the source receives new requests faster than the DTP can fetch them, the amount of source requests to be transferred will increase steadily.
    Source : https://forums.sdn.sap.com/click.jspa?searchID=5462958&messageID=3895665
    Re: Diff between Only Get Delts Once and Get Data by Request
    Check this blog as well : /people/community.user/blog/2007/06/21/sap-netweaver-70-bi-data-transfer-process-with-147only-get-delta-once148

Maybe you are looking for

  • Explanation about invoice reversal for standard price.

    Hi, Please see the excerpt from SAP help below. I extracted this example in sap help found at http://help.sap.com/saphelp_47x200/helpdata/en/fc/85c5371e5db25fe10000009b38f8cf/frameset.htm With regards to the example found below i dont understand why

  • How to print filename?

    Is there a way to print a jpg picture using any of the quicktime products (preferably the pictureviewer) with the filename of the picture somewhere on the page?

  • How can I avoid the writting of the field TRDAT (table usr02) when I logon?

    Hi guys! The first days of the month we have a high number or RFC processes with a generic user wich access to system at the same time from a remote aplication. This causes a lot of performance problems because of the update of the field TRDAT in tab

  • HP SimplePass 2011 and IE10

    SimplePass PE 2011 came preinstalled on my new HP computer and I've used it successfully with IE8 and IE9.  I recently installed IE10 and now SimplePass no longer works.  It doesn't pop up for any of the configured web sites.

  • Illustrator -- PDF

    When I save my Illustrator file as a pdf it saves blank. I am saving on a MacBook Pro. Any help?