cancel
Showing results for 
Search instead for 
Did you mean: 

Database Export/Import of Incremental Data

Former Member
0 Kudos

Hello,

We are using R/3 and BiW in our company...

We want to send data from R/3 to BiW every month and then users can fetch report from the BiW system...

Is it possible to send incremental data from one table of R/3 to BiW through Database Export / Import...

Can we Export Incremental Data from one table and then import it to the same table in BiW leaving old data intact and adding the new monthly data...

We are on Oracle 10.2.0.4 on both the systems...

Thanks,

RaHuL...

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

No, you cannot use DB export / import for incremental data.

Use Delta processing in BW. Ask your BW configurator about delta updating the BW Cube..

Mark

Former Member
0 Kudos

Hi,

Thanks... That was quick...

I was surfing through google and check command where it says you can give

where clause like " exp scott/tiger tables=emp query=\"where deptno = 20"\ or date between 'xxx and yyy "

Kindly correct if i am wrong...

Thanks,

RaHuL...

Former Member
0 Kudos

Hi,

All very well doing it in SQL........

But if you are running an BW system do it through Delta updating....It's supported through SAP

and you can run it all through a nice process chain.... : 0 )

Regards

Mark

lbreddemann
Active Contributor
0 Kudos

Using tools like exp and imp really is a bad idea to create a data interface between two systems.

As the others already wrote: when using SAP BI you would use delta loads to move data from your transactional system into your data warehouse.

Even if you use a different BI product - most of them will have appropriate data staging facilities that allow incremental data loading. Actually it's a very common requirement for data warehouses.

The core failure of this approach is to ignore the fact that "application data" is not "data in a table".

It's data in tableS - multiple tables.

In RDBMS data is stored normalized, that is: distributed over several tables.

And it usually does make sense only when put in context.

This context comes, again, from other tables.

So, either you have a well defined interface for the data exchange that allows the BI product to recreate the meaning of your data (like the BI CONTENT provides this) or you'll get a bunch of meaningless data into your BI.

It's pretty much the same mistake that is done in all those "we want to do ODBC access to our R/3 database" threads:

You're treating the RDBMS as if it is a bunch of flat tables - without any dependencies between them.

This is not the case and ignoring this fact won't lead to a succesfull, secure and reliable interface.

regards,

Lars