Tonny, a new BW pal asked me a question of the difference between the Transactional ODS and the Standard ODS. Frankly I just remember my SAP trainer mentioned it during BW3.5 Delta course, in APD (Analysis Process Designer) part; but never use transactional ODS in my projects, so I have done some research on it. Well, you always can search using key word of “transactional ODS” by Google; you might need SAP SDN and Service Market Place accesses to open some links though.

* I always prefer go to SAP Lib for information first, basically the difference can be summarised as below:

http://help.sap.com/saphelp_sem320bw/helpdata/en/ad/6b023b6069d22ee10000000a11402f/frameset.htm

1. The Transactional ODS contains only once table that is the Active table where as the standard ODS contains Active Data Table, New Data Table and change log.
2. So delta update from transactional ODS to other data target is not possible, however you can use a full update. You can not find “Update ODS data in Data target...” in the menu as for a Standard ODS.
3. When converting a Standard ODS to a transactional one, the update rules and transfer rules will be inactive.
4. Data can be read faster from a transactional ODS than a Standard ODS (no activation).   
5. A transactional ODS can not be used for a Query directly; however you can create an InfoSet based on it, in BW 3.5. In BW 7, with the new name “DataStore object for direct update”, it can be used as an InfoProvider for BEx Query.

http://help.sap.com/saphelp_nw2004s/helpdata/en/e3/e60138fede083de10000009b38f8cf/frameset.htm

* Then you might need a transactional ODS when:

1. in APD

http://help.sap.com/saphelp_nw2004s/helpdata/en/49/7e960481916448b20134d471d36a6b/frameset.htm

A simple case:

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/4419

2. Or want to read the data written to the ODS instantly (without activation).

Scenario 1:

https://www.sdn.sap.com/irj/sdn/thread?threadID=184702

We had data coming from two sources, one is from R/3 side and the other one is the dynamic data which the user enters. The client wanted to have the result of the user entered data instantly.
So for the user entered data was maintained in the transactional ODS and R/3 data was updated in a standard ODS. We combined the two ODS objects in an Infoset and created the queries.

Scenario 2:

You have data in an InfoProvider, and you have a query that provides you the results you are looking for, but the query does logic that you cannot easily replicate in any update rules.

So, you use an APD (Analysis Process Design) to use a query as a DataSource. Then you update a transaction ODS with that DataSource (a BW query). Then move the data from the transactional ODS to a reportable object (ODS or cube) for last combination in other reporting.

* Actually you also can Set the query as an ODBO, and use RSCRM_BAPI to create Query Extract (to table), or use MDX to realize.  

Scenario 3:

During planning, it is often necessary to maintain a comment (a short text up to 60 characters long) for each data record. This article explains (with sample ABAP code) how to maintain text fields like comments directly in the planning layout using then interface with Transaction ODS.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/60938938-de6f-2910-2080-fc80d38ebfec

* Available APIs when using transactional ODS objects:

http://help.sap.com/saphelp_sem320bw/helpdata/en/c7/dc833b2ab3ae0ee10000000a11402f/content.htm

* You might also be interested in the new member of DSO family in BI 7, “write-optimized DataStore Objects”, then you can find the details in SAP Lib via:

http://help.sap.com/saphelp_nw2004s/helpdata/en/e3/e60138fede083de10000009b38f8cf/frameset.htm