Hi,

Want to replace the facts table in an existing, built cube with another table
that's almost identical. And where the changed columns (in the new table) are
not involved in any of the existing dimensional joins.

In the Cube Editor, if you click in the facts table box below any of the column
names, you'll find a Replace item in the context menu. This then allowed me to
navigate (through my Data Source) to the new table that I want to use. Put it
in and the name changes.

However, when I then try any operation on this cube (Process, Save, etc) I get a
very simple failure message saying "Internal Error".

I've seen this before. And my solution was to find; dig out; and use the
MetaDataScripter. (or rather dump out the script; make sure that various names
were consistent [which were not]; and then run the script with consistent
names).

So I figure out again how to register the DLL/Add-in for MetaDataScripter and I
dump out the metadata for the cube (not db) in question.

Find the appropriate spot again in MetaDataScripter's ScriptFooter_Routines.bas
where one inserts the script generated previously.

VB (6.0 SP6) crashes. Repeatedly. I count the number of lines of script code
that were generated - something on the order of 86,000. Yes I can see how this
might crash vb.

I try copying in the script code in chunks of 20,000 at-a-time. This doesn't
help - it still crashes.

So ... various ideas

1) how to somehow increase the memory allocation for VB6.0 so that this amount
of inserted code doesn't make it crash.
2) go back to Analysis Mgr and figure out some better way of replacing the facts
table that doesn't produce an unusable cube.
3) I tried taking a subset of the generated script code and inserted this into
VB (I had taken out the Aggregation stuff since it's by far the largest piece
and I figured this might regenerate when I re-Process). And even with this
truncated amount of code, I get (another new VB experience). ROUTINE TOO LONG.
But maybe there's still a way of targeting my DSO changes (only want to change
the name of the facts table) so that it doesn't break whatever programming
environment I'm using.

pat

Fixed. I eye-balled the script generated by MetaDataScripter. The vast
majority seemed to be stuff to regenerate aggregations. Things with long
strings in them of the form:

"1111111111111111111111111111111111111111133"

I guessed that I might be able to remove all these from the script and that they
would all self-regenrate once I again had a consitent cube and ran Process.

I removed them and this reduced the ~86,000 lines of code to ~2,000!

So I then inserted this in ScriptFooter in the location under SCRIPT STARTS
HERE.

Immeidate Window - Call RunScript() RET

Compiler failure. Procedure too long. Shit was is this?

So I chopped up the 2,000 lines into to subprocedures Chunk1() and Chunk2() with
what I guessed was the necessary preamble (setup) copied identically at the
beginning of each.

VB no longer complained (or crashed). This ran and regenerated the cube.

I suppose a different solution to these limiations to VB6 would be to use the
VB.NET project that's also included with MetaDataScripter in the ResKit. I
tried this. I'm using VS.NET 2003, the provided code seems to have been
generated with some earlier version of .NET. It required me to 'Convert'
(update/whatever). I did so. Then ran a compile and got all kinds of undefined
symbols. I could have continued with .NET by regenerating from scratch from the
VB6. But instead I returned directly to the VB6 and found the work-arounds
above.

One would hope that VB.NET does not have the silly limitations that I found
above (VB crashing when fed to much code; and 'procedure too long').

pat


In article <d60pgh0jg2 (AT) drn (DOT) newsguy.com>, Patrick Flaherty says...

Patrick, instead of wrestling with the scriptor, you could write DSO to do
this as a much more concise approach.

In VB, or any .NET language you want (or any language that can reference DSO
for that matter), you can declare the cube as an MDStore, and change just its
fact table via DSO.

Sample vb:

Dim dsoDatabase as DSO.MDStore
Dim dsoCube As DSO.MDStore

Set dsoServer = New DSO.Server
dsoServer.Connect (strServer)

Set dsoDatabase = dsoServer.MDStores(strOLAPDB)

Set dsoCube = dsoDatabase.MDStores(strCubeName)
'set the fact table to the new fact table
dsoCube.SourceTable = "dbo"."NewFactTable"
dsoCube.Update

strServer is the string name of the server, strOLAPDB is the string name of
the OLAP database, and strCubeName is the string name of the cube...I'm
assuming these will get passed into your function somehow.

There are quite a few assumptions here. I'm going on the assumption that
this table joins to all the dim tables in your cube the EXACT same way the
previous fact table did, and that ALL columns necessary for all measures in
the cube are in the new fact table, and named EXACTLY the same. If this
isn't the case, other code will need to be written. However, if this isn't
the case, and all things above mentioned are exactly the same with the new
fact table, the above code should work. You may also need to tweak the
string of the source table depending on the SQL database that's providing the
data (i.e., Access wouldn't need the owner name, just the table name, etc...)

Good luck.

- Phil



"Patrick Flaherty" wrote: