Description:
This function reads and writes a point from an OLEDB compliant cube. You must specify the provider, data-source, database and cube to read from. You must specify a member for each dimension in the cube. The point is editable and when changed, gets written back to the OLEDB provider database. The OLEDBReadWrite function allows a user to pull in values from any OLEDB compliant data source, connects to a cube in the database specified, and selectively pulls in the data that you require from a particular dimension's member and brings this data into PowerOLAP. It also allows the user to write back values through any detail point, and these values actually get written back into Analysis Services. The cube in PowerOLAP is where the "Readable/Writeable" values are stored. This implies that once the OLEDBREADWRITE function reads values from the source, then in order to access these values they need to be stored in a location and the location is a cube in PowerOLAP.
The dimensions and their members in the cube in PowerOLAP must be an imitation of the dimensions and the members of the source cube in the source database (that are parameters to this function), existing within the OLEDB Compliant Data-Source from where we are pulling in data. The OLEDBReadWrite works just like the OLEDBRead function for reading data and the formula structure, and most part of the syntax also remains the same. However what changes is the fact that with OLEDBReadWrite a user can not only access values into PowerOLAP but once a connection is established, one can make appropriate and desired changes to the cube and actually send the data back to the source. So it works a little like the ReadWrite function already existing in PowerOLAP except that this function works from within PowerOLAP and it's aimed at writing back to an external data source. Although the cube in PowerOLAP must contain all the dimensions that exist in the source cube, however those dimensions need not contain all the members in the source data cube. You may create only those members within which you want to populate values, and display the same. These member names in which you pull in values, must match exactly with the member names in the source database and even a small typing error can be responsible for not pulling in values from the source cube because an exact match is completely necessary.
Syntax: OLEDBREADWRITE (provider, data-source, database, cube, member1, member2,…)
Remarks
Example
Let us create a new database to illustrate this example. This database is named "AnalysisServicesinPO" and contains a cube called "OLEDBReadWriteCube". The dimensions and their members in the "OLEDBReadWriteCube" are an imitation of the dimensions and the members of the source cube in the source database within the OLEDB Compliant data-source, which in this case for the example is Microsoft Analysis Service and this is from here we are pulling in data. In this example we are pulling in data into our cube in PowerOLAP from the "FoodMart 2000" database in MS-Analysis Services. In this instance we are using the "Warehouse" cube that exists within this database. Therefore the cube "OLEDBReadWriteCube" in PowerOLAP is a replica of the "Warehouse" cube in "FoodMart 2000".
This formula above reads values from the "FoodMart2000" database that resides on the data-source, which is the name of a server here, namely, "Escher". The cube that is read from this database is the "Warehouse" cube and for the member names, since we require all the values of all members to be pulled into PowerOLAP therefore we make use of the current function, which ensures that the member name being read by the OLEDBReadWrite function, is the currently selected member name, and when the selection changes the value is also updated. In this way the OLEDBReadWrite function accesses the values from analysis services. From a slice in PowerOLAP, when the user is at a detail member level, values can be written back to the cube and the same values will be updated and stored in the source database. There is also an option to "Begin Analysis", "Cancel Analysis" or "Commit Analysis" to assist the user in the write back process.