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