3.0(b) delta upload, missing new records while modified ok

Question: Hi schalasani,CHC,SR,Fans,
We are using 3.0(b). We are loading master data and transaction data. Both the master data and transaction data sources have delta upload checked. We have 10 customers. We loaded a full upload. Then we initialized delta. Then we made some changes to the customer master data. When the delta upload is scheduled, we got the changes carried over to BW. We added a new customer. This time, when the delta load is scheduled, this new record is not being loaded into BW. Infact, we got this message "The data request was a delta update, meaning the data basis in the source system has not changed since the last update. Info IDOC recieved with status 0. Check the data basis in the source system". The same is happening with the transaction data. What are we doing wrong?
We are able to load changes to the existing records but not new records. Why?
We really appreicate your help. We didn't find anybody experienced in the 3.0(b) version.
Thanks
- Gray

Answer:
i have replied to the PM u had sent regarding this problem..

Answer:
"community" generally means that we share...


Ch
_________________
_
There are only 10 types of people in the world :
those who understand binary and those who don't.

Answer:
Had the same problem once. I think you cannot load data via delta loads if there has been a full-upload from the same datasource before?!
_________________
Juergen Limbach

Answer:
that is not quite true..

u can always load a delta from DSs where u did a full load..

Answer:
if it is delta capable of course...

Answer:
Hi All,
Thanks for your inputs. Can there be an installation problem of the delta management software? Also, I was doing a full upload and then initializing the delta and then doing the delta upload. I think full load is not necessary whene you are going to do a delta upload right? Kindly give us all your inputs so that we will get this straight once for all.
Thanks
- Gary

Answer:
Gary, I don't think that you will got it for once even if we all give some inputs, because this part is sometimes tricky and depends on many factors ; but let's try to begin somewhere anyway...

It is true that it is not mandatory to make a full upload before initializing the delta. This is only a possibility to help you during the initialization phase in case you have a huge amount of records, for instance. And that's why you have this possibility "initialize without data transfer".

"Can there be an installation problem of the delta management software", well this is not exactly an "installation problem", but we all know that SAP 'sometimes' ship things that are not yet working 100% correctly... and I discovered during the investigation of a problem of mine that there are a lot of 'small' problems around delta loading, and this occured in several implementation (friend of mine was giving a delta course to experienced consultants, asking my question to them, and they nearly all replied with comparable experiences of loosing "sometimes" "some" data...) So, my advice on this topic would be "be careful, and don't always think that YOU are the guy who is doing something wrong...")

'hope this helps
Ch
_________________
_
There are only 10 types of people in the world :
those who understand binary and those who don't.

Answer:
Thanks CHC!,
That really helps. Hw can we afford to loose data and that too FI, AP data?
We want to automate the data loading process.
Thanks again!
- Gary

Answer:
Hi Fans,
The master datasource is 0customer_attr, and the datasource for the transaction data is "zfiap", the delta update check box is checked.
Thanks
- Gary

Answer:
Thanks CHC!,
That really helps. Hw can we afford to loose data and that too FI, AP data?
We want to automate the data loading process.
Thanks again!
- Gary

That's the problem. WE CANNOT afford to loose data. That's why whenever you discover such a kind of problem, you should really hassle sap via oss ot have a fix, as it helps the whole sap community.

Ch
_________________
_
There are only 10 types of people in the world :
those who understand binary and those who don't.

Answer:
With master data, you can run a 'full-load' to correct or sync. data with R/3 and still be able to resume delta-loads, as I've found from my experience. So you can always recover 'lost' master data. This however, doesn'y not seem to work for transactional updates, I've never taken the risk to try it on other than master data, in the production system.
_________________
Keep smiling

Answer:
Hi All,
Thanks for all your inputs. I will post again on this topic once I find a solution.
Thanks
- Gary

Answer:

...
It is true that it is not mandatory to make a full upload before initializing the delta. This is only a possibility to help you during the initialization phase in case you have a huge amount of records, for instance. And that's why you have this possibility "initialize without data transfer".
...

Ch

Just a few words of caution on "initialize without data transfer". This is just a simulation. It does not initialize the delta process such that the first delta request will bring back all the data -- which I had assumed. Note 424848 describes a program that appears to serve this function.

In the source system table BWOM2_TIMEST includes times of delta extraction. The update mode C is the initialization. Note 437853 includes a program to correct problems with this table.

Answer:
Robert, my meaning was the following, and I would like you to assess that this way of doing things is ok as I was confused by your remark.

If you "initialize without data transfer", no data is carried to BW. Next change of data in source system will be flagged as delta. Next time we do a delta load, this change is taken into account.

So, if the cube was empty before you did "initialize without data transfer", only the deltas since then will populate your cube.

If before you did "initialize without data transfer", you populated your cube with the historical data using full load(s), then everything is there.

Is it so ?

If this is ok, then people encountering problems with the initial load because of huge volume of data can load the historical data with smaller packages and then do this "initialization without data transfer" afterwards, being cautious about the fact that changes made between the upload via full load and the initialization are lost, so you better do it when no users/process are modifying the source of data.

Do you also agree with this second part ?

Ch
_________________
_
There are only 10 types of people in the world :
those who understand binary and those who don't.
Copyright ?2007 - 2008 www.jt77.com