My collegue, Kornel, posted this a couple of days ago, but we have not got
any reply. So I try to repost...
Basically the problem is we need to extract location of a cube-writeback
source table. There is a SourceTable property in DSO, but its behaviour is
not fully deterministic, in our opinion.

TIA
Szymon Slupik, CDN SA,
Krakow, Poland

==================

Hi, I want to restore OLAP database and to enable cube writeback option.
I do it this way:

1. Restore database (from within Analysis Manager)
2. Set DataSource (from within Analysis Manager)
3. Enable writeback on a cube (Write-Enable option from within Analysis
Manager, pointing SourceTable property to a writeback table)
After this step the SourceTable property of the writeback partition is not
persisted, it points to the original fact table, not the writeback table.

If between steps 2 and 3 I process the database (from within Analysis
Manager), everything seems to be fine, especially the SourceTable property
of the writeback partition IS persisted, it correctly points to the
writeback table.

The same thing happens when the above scenario is done via DSO.

I have noticed some posts about an old bug in v7.0, that the only way to set
SourceTable property is to do it with setting FromClause property
(unless it does not work) for example:
http://support.microsoft.com/default...NoWebContent=1

Trying to find solution to my problem I found that this bug is still (SQL
2000 SP3a) present, while trying to set programmatically SourceTable
property of
writeback partition before first processing of the database(!!!)

Any suggestions, is it a bug, or is there any known workaround?

Kornel.

Hi,

I have not reproduced the problem on my side. Here are my reproduction
steps. Please check if there is anything incorrect with the steps.
1. Restore database (from within Analysis Manager)
2. Set DataSource (from within Analysis Manager)
3. Right-click a cube, select "Write-Enable", accept default and click OK.

However, I am not sure how you check "After this step the SourceTable
property of the writeback partition is not persisted, it points to the
original fact table, not the writeback table.". Could you use Foodmart
sample to describe reproduction steps in more details?

In addition, 299930 KB article seems to describe a little differently than
yours. I am not sure if they describe the same problem.
299930 PRB: Unable to Set SourceTable Property of Partitions to a Different
http://support.microsoft.com/?id=299930


Bill Cheng
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
--------------------
80/support/kb/articles/q299/9/30.asp&NoWebContent=1

Hi Bill,

Have investigated things further. The behaviour is not reproducible on
foodmart, happend only on SQL Server data sources.
There is one important thing that influences this behaviour - we discovered
it yesterday. When archiving the cubes, we used to clear data sources before
the archive operation. The result was a very compact archive - just cube
structures, without data. Such archive when restored behaved like described
below. So the workaround for now is to back up cubes in a processed state.
To keep the archives small we will process the cubes off a small dummy
database (we need to back up only cube structures, not the data).
Best
Szymon

""Bill Cheng [MSFT]"" <billchng (AT) online (DOT) microsoft.com> wrote