In SQL Management Studio, only the entire DSV is scriptable - I don't see a way to script out changes to just some of the tables. I could, in theory, manually edit out the parts of the DSV that aren't related to my new entities, but it's not clear from the XMLA Alter command documentation whether that would work. But my reading, the command would replace the entire Major Object, which is the entire DSV in this case. Am I reading that right?
The only other option I can think of is to programmatically add the new entities to the DSV through explicit code - doable, but a royal pain, and I'd rather avoid it if possible.
Am I understanding things correctly? Is there some other option I'm not aware of?
You are right, the XMLA alter command would replace the entire DSV, so if you only scripted out changed objects that is all you would end up with.
You could programmatically add new entities to the DSV through code, but if you trace the resulting interaction with SSAS you will find that it is still doing an XMLA Alter and sending throught the definition for the entire DSV. But atleast if you programmatically add a table to the DSV, AMO will handle the scripting of the rest of the DSV for you.
|||Thanks for the confirmation, Darren. Fortunately, I came up with a slightly simpler way to do it than manually creating all of the new DSV entities in code. I'm loading up the full cube deployment script, plucking out the new DSV items, and copying them into the existing DSV. In the end, it's not too painful. Works well for new cubes and dimensions as well.|||Glad you have found a solution. I am just curious as to what you mean by "copying them into the existing DSV" are you doing an XML or text "diff" between your new DSV and the existing one?|||By that I meant using AMO to get the DSV on the existing database instance. Basically I'm getting the existing DSV schema (using AMO), parsing out the new DSV schema from the XML/A deployment script for the modified database, and merging the new elements into the existing DSV.I haven't gotten as fancy as an automated diff process (yet). Currently I'm just manually keeping track of what the new items are. Hopefully I'll be automate that more soon.|||
I thought you must have been doing something like this. It does seem like a lot of manual work. I'm not sure if you really need to go to all that effort. If you basically pass SSAS an alter script with the entire DSV from the deployment script it *should* be able to figure things out. (assuming that your development project is just an updated version of the project that was originally deployed to your server)
Would I be correct in assuming that the situation you are facing is that you have made mulitple changes to your solution, but you only want to deploy some of them - hence the need to manually script things out? I have been working with a friend on a project to build an add-in to BIDS (www.codeplex.com/bidshelper) to enhance BIDS and one feature we were thinking about was the option to deploy just a single object from a project. I have a sub set of this working where I can deploy just the Calculation Script from a cube. If you are interested I don't think it would be too hard for us to add some basic "deploy single object" functionality that would handle other object types.
|||>assuming that your development project is just an updated version of>the project that was originally deployed to your server
And that's the rub - it's not. We are an ISV that includes a set of SSAS cubes in our product. We provide a UI for customers to extend the cubes with custom measures and dimensions. When we ship new versions of our software, we need to be able to deploy our changes (new cubes, dimensions, attributes, etc) without overwriting the customer's customizations.
The BidsHelper project looks pretty cool - I'll check it out. Ultimately, it doesn't sound like something we'd be able to take advantage of to solve our problem - but it may come in handy during development.
|||
Aah, now I see where you are coming from.
I am not really aware of any good way of handling this "out of the box". It sounds like you will either need to write custom AMO code to attach to the client database and modify them. Or you would need to store the customisations that customers apply so that they could be re-applied after an upgrade.
It sounds like a reasonable feature, you could log this as a suggestion on the connect.microsoft.com site under SQL Server if you would like to see it considered for a future version, but in the medium/short term this sounds like something that will need custom code.
|||Hi Kevin
Need your help desperately
as i read in ur message that you are updating the data source view by AMO
please let me know how to do that
I am working on the SSAS project and we need to add the measure dynamically to the cube( can be SSIS or Amo any thing, it should be automatic)
I am not getting the way to do that
please send me the detail to do that
that will be a big help
thanks
|||There is a product sample that shows how to build a lite version of the Adventure Works database from scratch using AMO.
http://www.codeplex.com/MSFTASProdSamples/Wiki/View.aspx?title=SS2005%21Readme_AMOAdventureWorks&referringTitle=Home
If you are dynamically adding measures you would need to update the DSV, add the measures to the appropriate measure group and reprocess all your data.
No comments:
Post a Comment