DCSIMG
How to avoid breaking reports based on your Report Model - Ella Maschiach's BI Blog

Ella Maschiach's BI Blog

BI, Olap Technologies, Tools, System Analysis and Design

News

About Ella Maschiach

Business Inteligence

How to avoid breaking reports based on your Report Model

Almost every post I made about Report Builder, be it the pros and cons of creating a report model on a cube or refining a report model based on a cube, brought the same question - what makes reports based on a report model to break and how can you avoid it?

Well I didn't know the answer as I admit it never happened to me, (sigh of relief), but the question did bother me enough for me to try and research it a bit more on the internet. And yes, I'm happy to say there is more than enough information on the internet for me to come back with some answers:

  1. There's a summary from Bob Meyers on what will break your reports when you change the properties of attributes, entities and roles in your Report Model.
  2. Yes, Bob Meyers knows SSRS inside – out, and if the above post was a summary, then this one elaborates on some of the points mentioned before and will give you great tips on how and why to denormalize your Report Model. So read it also!
  3. Msdn has also dealt with the issue of what will break reports based on your Report Model. This article relates to Report Model management in SQL Server 2008, and this one for Report Model management in SQL Server 2005. The articles are one and the same for the time of writing this post, but that may change in the future.
  4. Apparently what Bob Meyers said about avoiding changes to an object's ID in Report Model, also holds true when you do that in your SSAS cube, when your report model is based on it. Steve Novoselac gives you the details on what happens because of it.

Hope that helps you avoid breaking the reports you have based on your Report Model, so that your users can keep running them!

Posted: Jun 08 2008, 09:57 PM by Ella Maschiach | with 5 comment(s)
תגים:, , , , , ,

Comments

Trevor said:

Hi Ella

I was updating my report model by deleting the existing one and replacing it with a new one - stupid I know. The result was that my users ad-hoc reports created in Report Builder no longer work. To solve the problem requires remapping the data source to the new model. I could do this with my reports because I have access to the My Reports folder in Report Manager. I cant do this with the users reports as I cannot see the "Users Folders" folder in Report Manager. I cant expect them to change all their reports themselves. What governs the security to be able to see the Users Folder folder. Our company policy will not allow me to be mapped as a local administor on the server where the reports reside. Is there any other way for me to get this access??

# January 6, 2009 7:21 AM

Ella Maschiach said:

Hi Trevor,

Well unfortunately enough I come back to you without a solution. Only if you're an Administrator on the server itself (where the reports reside) can you see the Users Reports folder. If it consoles you, even if you see the Users Reports folder I can't see how it would help you. At most, you'll be able to see the details of who and when created the report. You cannot (even as an Administrator) open reports under My Reports of a different user (not even through Users Folders).

I heard that a Microsoft Consultant that was here about 2 year ago and moved our RS Server said there is an add in application to look at the users reports and run them, but nobody seems to remember the name, and I couldn't find anything on the web…

I think your users will have to change their reports themselves.

All the best,

Ella

# January 7, 2009 9:35 AM

Jeff said:

We programmatically generate report models. However, the report breaks because all the IDs in the report model are GUIDs and they change whenever an existing model is updated.

Is there a simple way to update an existing model without having it change all the IDs? The only way I can think of is to traverse all the nodes and copy IDs from the old model to the new model if entity name matches, etc. Any suggestions?

-Jeff

# January 16, 2009 9:13 PM

Ella Maschiach said:

Hi Jeff,

Well I assume what you mean to say is that you delete old attribute and re – create them using the "Autogenerate" action. This produces the same attribute with a new GUID (which causes reports with the same attribute with the old GUID to break). If you'd like to link an attribute to a different field, just stand on it. In the properties pane for that attribute, look at the "Binding" property and click next to it. That should enable you to use the same old attribute (with its GUID) with another filed from the DSV.  

You can also open the Report Model SMDL file as "View Code" and look at its XML. There you can delete and write what you like, but I really wouldn't recommend that, as I think it's very easy to get lost there and I much rather use the UI of the BIDS.

Hope that helped,

Ella

# January 18, 2009 9:14 AM

How to avoid breaking reports based on your Report Model « A Blog for SQL Server Reporting Services (SSRS) Programmers said:

Pingback from  How to avoid breaking reports based on your Report Model « A Blog for SQL Server Reporting Services (SSRS) Programmers

# June 17, 2010 10:28 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: