Full-Init-Delta Loads

Friends
I have done full loads into a ODS and then I did Init with no data transfer. But the Message said that the request cannot be activated because the ODS has had full loads and activating INIT and DELTAS is not possible...Any Ideas?
Regards
VISHAL

Hi Ashwin,
there is a seperare procedure to activate delta mechanism in ODS. After you load the full requests you cannnot run init without making all the full requests to "Reapir full requests".
See SAP Note: 689964
Symptom
You want to switch the upload procedure for an ODS object from full to delta. However, the delta initialization fails with a message indicating that there are already full uploads in the ODS object and therefore inits or deltas cannot be posted or activated.
Other terms
Delta; ODS object: delta initialization, RSM 098, full, Init
Reason and Prerequisites
If a full upload occurs once for an ODS object, you can no longer activate an init for the same DataSource/source system combination in this ODS object. The system does not check for overlapping selection conditions.
Solution
In the case if an ODS object, you can change the upload procedure from full to delta by subsequently marking the full requests that exist in the ODS object for this DataSource/source system combination as repair full requests.
These requests are therefore characterized by the fact that they can be posted into any data targets in any sequence. The repair full requests are never checked in a data target, that is, you can activate initializations and deltas (also with selections) in the ODS object. All ODS objects filled with these full requests behave as if the full requests did not exist in the ODS object.
Checks do not take place in all of these ODS objects.
Note the following:
Since the repair full requests are not checked, duplicate data records may be created or data may disappear if there is a subsequent init.
Since the repair full requests are not checked, you should take account of the extractor behavior, update modes, aggregational behavior of key figures and characteristics, among other things, when you are deciding whether you want to mark the full requests as repair full requests.
If you perform an init simulation after changing to repair full requests, make sure that no data is updated between the last full upload and the first delta upload.
Procedure for changing full requests to repair full requests:
After you import Support Package 19 (3.0B) or Support Package 13 (3.1C), the RSSM_SET_REPAIR_FULL_FLAG report is available which you can use to convert all full requests for a DataSource/source system combination that are in an ODS object into repair full requests.
Before you import this Support Package:
Use transaction SE16 to call the RSSELDONE table.
Here, enter an "x" in the "Repair_Full" field for all full request records that you want to mark as repair full requests.CAUTION: This ONLY concerns those requests that begin with 'REQU_...'. The repair flag CANNOT be set for activation requests that begin with 'ODSR_'.
If the full requests still exist in the PSA, you can also use the scheduler under the 'Scheduler' menu option in the PSA tree (when you post from the PSA) to switch a PSA full request to a repair full request before loading.
If you load new requests with an InfoPackage, you can also assign the repair indicator to this full report.

Similar Messages

"Error occurred in the data selection" on init delta load ODS- InfoCube

Hi, gurus and experts!
I'm trying to do Init delta load from 0FIAR_O03 ODS into 0FIAR_C03 InfoCube in PRD env. by InfoPackage "Initialize with delta transfer (with data transfer)". Immediately after the load was started I got error
"Error occurred in the data selection"
with details
"Job terminated in source system --> Request set to red".
Where are no any short dumps. There are 1 activated init load in ODS - nearly 6 500 000 records.
Any ideas about error? And the way I can load data?

Hi Gediminas Berzanskis,
I faced the similar error when I tried to load data from an ODS which contained huge amount of data to a Cube. Even in your case the volume of data is more (around 6.5 million records). The error could be due to the table space issue, please contact your Basis team to check if enough table space exist for both the data targets.
Meanwhile you may also check the RFC connection of the Myself source system.
You can replicate the DSO datasource once and then reactivate the transfer rules using the program RS_TRANSTRU_ACTIVATE_ALL.
Try load with a small amount of data with a Full load option and then with a delta option..
Hope this Helps,
Prajeevan (XLNC)

0FIGL_O02 Init/Delta loading, Why more data ??

Hi,
We usually load the 0FIGL_O02 using the 0FI_GL_4 extractor in Full mode.
Because of the very long loading time, we decided to use it in Delta mode instead, so we deleted all the data inside the DSO and we lunched the Init loading.
The situation is :
In full mode we load approx. 6 Million lines,
Everyday full loading inserts approx 200.000 more lines,
So when we converted to Init in day D, we were expecting to load approx. 6M and 200.000 lines of data, But we have now 9 Million, and still loading (not finished yet).
Why don't we have the same number of loaded lines ?
We are sure that we don't have 3Million new lines between D and D1, and we were loading in full with constant value of 6M (20000) everytime.
Is the Init load accessing other tables than the Full ? and are we having the good informations ?
Please help !!
Regards
Raed

Hi,
I am curious to know the finding for this.
We are also planning to reduce teh load time for 0FIGL_O02.
Thanks
Mukesh

Changing From Full to delta load

Could someone please help with this
i have used a Functional Module to extract data from R/3
i have created a new InfoCube and did a full load and everything is fine
There is NO ODS involved
i now want to change data loads from FULL to DELTAs
Can i do this without using an ODS and RECORDMODE - if so, how?
Thankyou
Pushpa

HI Pushpa,
For generic DS we need to maintain the generic delta. We can define in three ways.
1.Calday
2.Numeric Pinter
3.Timestamp
If we go for calday then there should a field (0calday). Which holds both created and changed the date of the record. We have 1 drawback in this we can only run the load only at the end of the day.
Numeric Pointer will only fetches the changed records.
Most of the time we preffer we go for timestamp.
U will get these option in RSo2 in R/3
Regards

Full and delta loads

Hi,
Is there any procedure (program or table) to find out list of fullloads and delta loads in BW system?
Regards
Jaya
Edited by: Jayalakshmi Busetty on Feb 19, 2010 6:04 AM

Hi Jayalakshmi,
Your can find in datatarges in Manage Button.
Thanks & Regards,
Venkat.

Full to delta load in generic extration

Hi All,
I am loading the data form R/3 to BW with full load by using the generic data sources.
Now I need to change the full load to delta. But I get the data 2 views and one FM.
Some what I have got the solution, that is going RSO2 there generic delta will be available
If I click I will get the one wind there 3 deltas form there I took time stamp. Then I need
Select the field name.
1) Now only my problem started in that field name there is no creation
Date and last changed data, based on this we need to get the data from R/3 to BW.
2) In that 3 datasorce I used the one DS function module in this also that field name is not
available .
3) In safety interval what I need to give.
Please help on above 3 issues.
Thanks
kumar.

Hi,
plz check with this most proberly it works.
Go to RSO2 >> Now select the right option(Transaction data,Master data attributes or texts) >> Now in the next screen enter the Application Component >> enter the descriptions >> Now select how you want to populate data in your data source .....following options are there :
View/table >> Choose the extraction from view button if you want to want to extract the data from a transpatrent table or database view,and enter the name of the table or view...the extraction structure of the generated datasource is then identical to that of view or table.......
SAP Query/Infoset>> Choose the extraction from query button if you want to use SAP query infoset as datasource..then select the required infoset from the infoset catalog...you can go to the screen for maintaining an existing infoset by double click on its name...
Function Module
To make your datasource delta enable >> Click on Generic Delta on the top >> Here first give the field name .This field from the extract structure of a DataSource meets one of the following criteria:
1. The field has type: time stamp. New records to be loaded into the BW using a delta upload have a higher entry in this field that those which have already been loaded.
2. The field has type: calendar day. The same criteria applies to new records as in the time stamp field.
3. The field has another type. This case is only supported for SAP Content DataSources. In this case, the maximum value to be read must be displayed using a DataSource-specific exit when beginning data extraction.
Now choose one of the three options :
Time Stamp
Calender day
Numeric pointer...
Safety Interval Upper Limit >>This field is used by DataSources that determine their delta generically using a repetitively-increasing field in the extract structure.
The field contains the discrepancy between the current maximum when the delta or delta init extraction took place and the data that has actually been read.
Leaving the value blank increases the risk that the system could not extract records arising during extraction.
Example: A time stamp is used to determine the delta. The time stamp that was last read is 12:00:00. The next delta extraction begins at 12:30:00. In this case, the selection interval is 12:00:00 to 12:30:00. At the end of extraction, the pointer is set to 12:30:00.
A record - for example, a document- is created at 12:25 but not saved until 12:35. It is not contained in the extracted data but, because of its time stamp, is not extracted the next time either.
For this reason, the safety margin between read and transferred data must always be larger than the maximum length of time that it takes to create a record for this DataSource (with a time stamp delta), or it must display an interval that is sufficiently large (for determining delta using a serial number).
Safety Interval Lower Limit >> This field contains the value taken from the highest value of the previous delta extraction to determine the lowest value of the time stamp for the next delta extraction.
For example: A time stamp is used to determine a delta. The extracted data is master data: The system only transfers after-images that overwrite the status in the BW. Therefore, a record can be extracted into the BW for such data without any problems.
Taking this into account, the current time stamp can always be used as the upper limit when extracting: The lower limit of the next extraction is not seamlessly joined to the upper limit of the last extraction. Instead, its value is the same as this upper limit minus a safety margin. This safety margin needs to be big enough to contain all values in the extraction which already had a time stamp when the last extraction was carried out but which were not read. Not surprisingly, records can be transferred twice. However, for the reasons above, this is unavoidable.
DataSource Is Real-Time Enabled
The "Real-time enabled" indicator determines whether a delta-enabled DataSource can supply data for a real-time demon.
If the DataSource finds the delta generically using a delta-relevant field, observe the following with regard to the safety intervals:
The safety interval at the lower limit may cause redundant data to arrive in BW. This data is not suitable for InfoCubes and ODS objects with key figures that are updated in appended order. With real-time updates, the redundancy of the data is increased by the short time spans between the individual runs of a real-time demon. With a lower safety interval of 2 minutes and a demon frequency of one per minute, all data may potentially arrive in the PSA three times. This can lead to database and runtime problems.
The safety interval at the upper limit makes the data less up to date. How up to date the data is with real-time is always the sum of the upper safety interval and the time span between two runs of the demon.
The system uses the delta type to determine how extracted data is to be interpreted in BW, and into which data targets it can be posted.
A distinction is made between the following:
1. Additive delta
The key figures for extracted data are added up in BW. DataSources with this delta type can supply data to ODS objects and InfoCubes.
2. New status for changed records
Each record to be loaded delivers the new status for the key figures and characteristics. DataSources with this delta type can write to ODS objects or master data tables.

Init. Delta load in BI 7.0?

Hi, Experts:
I just changed to a new BI application team. We have a delta load from ECC into an ODS then into a cube. I thought that there must be an initial delta load before the daily delta load. But I don't see init delta load request when right click the ODS/cube then select "Manage". The application started to load from January 2008. I have put the request display date to sometime 2007 then click the refresh button. But still could not see init delta load. From the very 1st load till date, I only see all are delta loads. Is this some thing new in BI7.0 that init delta is not needed any more? Or something is wrong?
Thanks,
Jenny

Hi,
that's right, there is no special request for Delta/Init.
The DTP can do it itself at the first time.
If you want to check which DTP is the Initialization, you can go on the DTP log, and in the header you will see "Extraction Mode" -> Delta.
If the corresponding DTP request is the init, the flag "Delta Init" is ticked.
Hope it helps !
Mickael

Full vs. Delta Load

Hi BI-Experts!
This is a rather general question.
Is there a recommendation when to use Full or Delta Load?
I know the functional differences but do SAP or some technical reasons say that each of them may only be used in special cases?
For example Delta Load can only be used with SAP source systems?
Best regards,
Philipp

Hi Philipp,
This is a pretty open-ended question. I will give you a few examples of when I use each ....
Delta's:
1.) If the record set is large and changes a lot daily. If you have a large initial load, let's say 2Million records and you get about 200k records per month, then you want to use a delta mechanism. There are just too many records to reload daily.
2.) If the record set is wide (many fields instead of a few), it will take less load time to run a delta than a full load.
3.) Datasource restrictions....some business content datasources don't have full loads and vice versa (some don't have deltas).
4.) Do my loads take too long? If so, I will convert full loads to delta's to shave off time here and there.
Full
1.) I gauge this mainly based on load time. If it takes 5 minutes to load 100k records, then it's going to take longer to figure out what delta's were missed (if there was a problem) than it would to just reload the dataset.
2.) Do my requirements dictate that I need to drop and reload the dataset? The best example of this would be the current year's forecast. Some companies revise the forecast and don't want to keep any previous revisions.
3.) Some data loads load a snapshot of a specific date. So, if I wanted to take a snapshot of inventory in a DSO/ODS on Monday, I would Datamart it into a Cube doing a full load for Monday's date.
Hope it helps!
Thanks,
Brian

Difference between delta load and full load

HI,
i am getting confused with full load and delta load.
The scenario is as follows:
I have 4 records which i need to pass to DSO.(Standard DSO)
These are the fields and records.
IO_amount          io_QTY         0UNIT     0CURRENCY     Matnr
1519     195     EA     USD     MM01
2643.85     12     EA     USD     MM02
3580.4     10     EA     USD     MM03
6049.8     12     EA     USD     MM04
Now i need to change the record as
IO_amount          io_QTY         0UNIT     0CURRENCY     Matnr
1500     195     EA     USD     MM01
2643.85     12     EA     USD     MM02
3580.4     10     EA     USD     MM03
6049.8     22     EA     INR     MM04
When i passed it as full and delta load but could not make out any difference..
I can see the data only in active data and change log tables.how can i see that in DSO?
please help out,Points for sure.

Hello Susmitha,
You are right & your view of data is also correct
But only thing here is ODS which you are using mait have Overwright option in its Update Rules /Transformations
Here Q is
Which fields are in KeyFields in DSO Design
If
this Field Values are same in Delta are Full Upload
it will overwrite the records in ODS / DSO
If not
it will add the records to DSO /ODS
Comming to Delta & Full Loads
If you use Full always all data Present will be loaded
if you use Delta always changed & New records will be updated
This happens through Pointers Set ( Snap Shot of Previous Load )
Some tables where you can see RSOLTPSOURCE,RODELTAM etc
Try to wiew this ,Its tough to get
Thanks
Hari

Coverting Full load to delta load

Hello All....
I have an infosource which was delta enabled, but by mistake somebody has done it Full Load.Now i dont want to teminate the job.
Can nybody tell me what will be the effect of doing full load & what should i do to convert it to DELTA load again?
Plz help...

Hi,
With a data transfer process, you can transfer data either in FULL extraction mode or in DELTA mode. In FULL mode, the entire dataset of the source is transferred to the target; in DELTA mode, only the data that was posted to the SOURCE since the LAST data transfer is transferred.
So I believe you should be fine as it would only transfer the data from change log which was LAST posted in to your changelog table of datastore.
However;this is my theory and understanding derived from SAP help,might worth taking a shot if you are in DEV or wait for some one from SAP to confirm on the same.
NOTE - Applies only if you want to MIX FULL and DELTA loads of DTP in ODS Datastore ,then activation of REQUESTS could create problem so follow below solution.
Note 967100 - P10:Activate DTP requests from full and delta DTP in DSO
Hareesh

Delta load from r3 to bw ?

i have one question on the mechanism of data transfer from r3 to bi 7.0. the followings is my concerns:
scenario:
The total numer of data is 1000 rows and these rows are seperated into 10 data package , each package contains 100 rows.
Now bw is trying to recieve these 10 packages from r3 in sequence.
When 5 data packages have been transfer to bi psa. the network is broken and the tranfer is canceled at the 6th data package.
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS.
How to find out how many records have been transfered from r3 to bw while the transfer has ended in
the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube.
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle ?
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer.
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Last doubt, what is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request ?
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
Please I am having all these doubts and I want you SAP experts to answer them please so that I can clear my doubts in production support . I really appreciate if someone explain me the scenarios here. It will be a really great help if someonce clears these doubts.

Hi......
What i want to know is when the network is reconnected ,Does the transfer start from the 6th data package?
If your connection is broken in between......inspite your load is through PSA...........you have to delete the request from the target(after making the QM status red)............then you have to reload it again............But before repeating the load check the connection is ok or not in SM59........
How to find out whether its a delta load or a full load if a transfer is scheduled from r3 to bw ? For both CUBE & ODS
This you can check in IP scheduler in the Update tab...........whether it is delta or full load.......
or you can also check in IP monitor(You can go here through RSMO..........IP monitor screen will open directly here............or you can also go through RSA1>> Find your IP >> Double click on it >> Click on the monitor icon in the top >> From the you will go to the IP monitor>> the under the Header Tab you can see whether it is a delta or Full update...........
Or you can check the datasource also..........
If it is a generic datasource go to RSO2..........and check...........If it is a standard datasource check it in RSA5...........
How to find out how many records have been transfered from r3 to bw while the transfer has ended in the middle ? I mean how to check how many records have been successfully transfered from r3 to cube/ods .Please tell me for ods as well as cube
Your load cannot be ebded in the middle.........it can failed.............if it fails then you have to delete the request from the target..........and then repeat the load.......
Is the continuation of transfer process is same for both ODS & INFOCUBE, if it ends in the middle
Yes.........
What is the procedure for full load & Delta load in case of CUBE & ODS ? I mean how to reschedule the transfer
If a full or delta load fails after extraction got completed due lock issue or SID issue.....etc..........and if you load is through PSA.............then just delete the request from the target without making the QM status red.......and reconstruct the request.........no need to repeat the whole load again........
But if you r load is not through PSA..........then make the QM status red........delete the request from the target........and repeat the load...........
And if the whole scenario is is in the support, SO I will be handling these issues on the live production server. Am I right ? So in this case my user id should have access to all the production r3 and production bw to do these change status to red and delete the request and reload the request etc., So I should be logging on to the production server and do all the manipulation, Am I right ?
Yes.......
What is repair request and so if the transfer stops in the middle we change the status to red and reload the request again , Is it called repair request or reload request?
Suppose you delta load has failed ............and you have deleted the request from the target without making the QM status red............In this case your data will be lost and your delta mechanism will get corrupted............In this situation.............
1) Delete the init flag........
2) You have to do Full repair..........(After filling the set up table)
3) Init without data transfer to set back the init flag
4) Then Delta upload.............
In case of an ODS............you cannot load Full update and delta upload parrallely..............Your ODS activation will fail...........suppose you want full upload in the ODS..............then you have to go for Full repair............
What is the difference between repeat delta & repair request & repair delta ? When do we choose these options, In which scenarios ?
I think Full repair concept is now clear............
Suppose your delta load fails...........After that you delete the request after making the QM status red............Then system will ask for a repeat delta when you will try to repeat the load...........which means it will pick the same delta records of the failed load..........
How do we schedule a daily load job from r3 to bw without the use of process chains ? I mean daily it should fetch the records from r3 to bw from the SD datasources at 10.00 PM ,how do we do that ?
This you can do via infopackage or infopackage group...........schedule it at the specific time.....
Check these links :
http://help.sap.com/saphelp_nw04/helpdata/en/20/ad673844a7114be10000009b38f842/frameset.htm
Re: Schedule Infopackage for last day of a fiscal period
Hope this helps you.........
Regards,
Debjani...........

Doubt in Delta Loading !

Hi,
I have a Doubt in Delta Data Loading
Please check the following Procedere is Right / wrong ?
I did Full Load it is successful.
I am doing Delta Loading.
For the Business Content Info Cube 0COPA_C01 --
CO-PA: Published Key Figures I am Loading the Data.
I am doing INIT & Delta Load.
This cube has the Data source 1_CO_PA_110_BILDA
I had checked in RSA6 : 1_CO_PA_110_BILDA
ExtractStruct : ZOXGDV0108
Direct Access : D
Delta Update is check -
First I Created a info package --
In Update Tab
Update Mode
Full Update
Delta Update
Initialize Delta Process
Initialization with Data Transfer
Initialize without Data Transfer
I have choosen Initialize Delta Process -- Initialization with Data Transfer
Then For the DTP --
In DTP -- Extraction tab -- Extraction mode is set to Delta.
There is no difference in Records when I loaded Full/Delta.
showing same records.
is the Right Procedure I followed !
When Next time I load Delta then I need to follow the Same procedure ?
Thanks
prasanna

Hi Prasanna
I thought that u r in to Bw 3.x
Ny ways in this case u should create a proces chain..
and schedule it in the start process it self .
Still there is one ancient option like define the subsequent process in the in fo pak
schedule once the PSA request is sucessfull then put a Event and then place the
same event in the start process or scedule process of DTP.
But as per Expert Suggestion U should Go for Process chain.
Thanks & Regards
R M K
**Winners dont do different things,they do things differently**
> Hi R M K thank you,
>
> if we do Info Pack -- schedule Tab
>
> In the option Start Later in background-- set
> periodic values
>
> Then it will update only in PSA.
>
> But if we want to get these Records in info cube
> we need to Execute the DTP.
>
> That is not doing.
> (selecting the option start later in background and
> set the periodic values is sufficiant)
> here you are not discussed for DTP.
>
> cause i don't want to load manually.
>
> How do we Execute DTP automatically ?
>
> thanks
> prasanna

Manging delta loading in 0FITV_C01

Hi Experts,
I have the following cube implemented: 0FITV_C01, with no DSO in the flow.
I'm interested in managing delta for this infocube, but when i've created the infopackage, only full upadate is allowed (consistent with what i found later online).
So, i'm wondering if the following steps is the best aproach to manage delta.
1) create a flow (3.5): infoprovider in full update mode, and in PSA only mode
2) create a DTP, from datasource to cube, in delta mode. In this case what Infopackage should I have on the DTP "tree" - with what characterisctics. I supose it can't be the same infopackage as mentioned in 1)
3) create process chain with 1) followed by 2)
Q: How would I do the initial loading? Is it like old BW? Meaning, I would first set the DTP to full for first loading, and then change it to delta?
From your experience, is this a good aproach? would you suggest any other thing to load data in delta mode?
Many thanks
Joana

hi
Ful load is used to load the data based on the selection conditions from your source to target.
Init is used to enable the delta mechanism for your targets.
It is always recommended to have separate infopackages for
1) Initialization
2) Full Load (Repair Full)
3) Delta Load
Init loads are of two types: With data and without data. Init intializes a pointer or counter in the source which helps to bring only new data from the source, rather than bringing the complete data once again. Now With data transfer brings the first time data as well as sets the counter where as the Without data transfer only sets the counter and no data is transffered.
Another Type is there Repair full Request.
If you are in BW 3.5, then it is not possible to do separate initializations to different targets from a single source.
For ex, you have the data flow from DS1 to 3 targets,
DS1 --> cube1
DS1 --> cube2
DS1 --> cube3
Then when you do Init with data transfer, you have to select all the targets and do it simulataneously.
If you have loaded to only one target, say ODS1 and want to load the same init data with data transfer to other ODS, it will not be possible.

COPA Init Delta

Hello,
In loading our COPA cube from R/3 to BW, when we run two init delta infopackages in parallel, we get the following error "An init or delta request is already running for this DataSource".
We believe this has to do with the timestamp functionality. According to the documentation we have found, it appears as though we should not split our init delta load into multiple infopackages, but rather limit it to one singe infopackage that loads everything. Can anyone confirm this?
Our COPA datasource is costing based and set up as a generic delta. We are on R/3 PI 2004.1 and BW 3.5.
Thanks,
Kelley

Hi,
That is right, and it will have to do with the timestamp functionality as you said.
Following is from the HOW-TO document which is not exactly for this scenarion but implies the same reason.
"There can only ever be one valid initial package for a DataSource. If, for the same DataSource, a separate initialization is scheduled for different selections, for example, and data is posted to the operating concern between the individual initializations, data inconsistencies could occur between SAP BW and OLTP. The reason for this is that, with each initialization, the time stamp of the DataSource in the OLTP system is set to the current value. Consequently, records from a previous selection are no longer selected with the next delta upload if they were posted with a different selection prior to the last initial run."
hope this helps..
cheers,
Ajay

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.
If I need to delete and reload do I first need to run an INIT DELTA load?
Thanks

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

Full-Init-Delta Loads

Similar Messages

Maybe you are looking for