Databases Reference
In-Depth Information
.
Tuples that don't exist in a measure group (in cubes that contain more than one
measure group). In such cases, the
UPDATE CUBE
statement returns an error even
when the
IgnoreUnrelatedDimension
property is turned on. For example, you
cannot update a cell referenced by the tuple (
[Customer].[Customer].[CustomerName].
[Alexander Berger], Measures.[Units Ordered]
) because the
Units Ordered
measure belongs to the
Warehouse
measure group, but the
Customer
dimension is
not included in the
Warehouse
measure group.
.
Cells associated with members in indirect dimensions such as referenced, many to
many, and data mining. For more information about dimension types, see Chapter
8, “Advanced Modeling.”
NOTE
Client applications can determine whether a cell is updatable before executing an
UPDATE CUBE
statement by using the
UPDATABLE
cell property. For more information
about how to use cell properties, see Chapter 11, “Advanced MDX.” If you are writing a
client application that performs either temporary or permanent writeback, you can add
this property to the request and allow or disallow update capabilities to users of your
application.
The value of the
UPDATABLE
cell property is a bitmask whose value is positive if a cell
is updatable and negative if a cell cannot be updated. In addition to the success or
failure information, the property value contains bits corresponding to the causes of the
failure. You can find all possible values of this property in SQL Server Books Online.
Lifetime of the Update
As mentioned earlier, the main difference between permanent and temporary writeback is
the persistence and availability of the changes. With permanent writeback, updates are
stored on the server; with temporary writeback, changes are available only on the current
session to the user that issued an update.
Typically, the
UPDATE CUBE
statement executes inside a transaction. A transaction starts by a
BEGIN TRANSACTION
statement, one or more
UPDATE CUBE
statements execute, and then
either a
ROLLBACK TRANSACTION
statement executes to roll back and discard the changes or
the
COMMIT TRANSACTION
statement executes to commit and store the changes on the server.
In addition to such explicit transactions initiated by a client request, Analysis Services
supports implicit transactions. In other words, if you have not explicitly started a transac-
tion by using a
BEGIN TRANSACTION
statement before sending an
UPDATE CUBE
statement,
Analysis Services implicitly starts a transaction for you. The changes from an
UPDATE CUBE
statement called in an implicit transaction are available only on your session and aren't
stored on the server unless you explicitly execute a
COMMIT TRANSACTION
statement to save
your changes on the server. If you delete a session before committing the implicit transac-
tion, Analysis Services automatically rolls back your changes.
Search WWH ::
Custom Search