Evolving your report model over time


Many factors combine to make report models highly likely to change and evolve over time. Sometimes the underlying schema changes. Sometimes new stuff is added. Sometimes you just want to improve how the schema is presented to users. Report models are designed to accommodate just these kinds of changes.


One of my earlier posts mentions several changes you can make to your models without breaking reports, as well as one that will break reports. Generally speaking, though, I believe you can change anything except the following in a report model, and existing reports will still run:



Entities: ID and Inheritance properties


Attributes:.ID, DataType, and IsAggregate properties, and entity membership


Roles: ID and Cardinality properties, entity membership, related role and its cardinality and entity membership.



Note that if you change attribute expressions, entity/attribute/role bindings, or the definitions of tables and columns in the DSV (e.g. by modifying a Named Query), you may get different results, but the reports will still run.


Obviously, you can organize and re-organize things in and out of folders as often as you want, and all your existing reports will still load and run just fine.


Also, if you want to “deprecate” a field, you can use the Hidden property to exclude it from the design-time experience in Report Builder. This will not affect existing reports.

Comments (2)

  1. czeke107 says:

    When updating a report model and re-deploying it to the report server the Ad-hoc reports that already exist break.  Any idea’s on how to correct this issue?  I’ve re-associated the data source and get another error saying the xlms and xls have already been declared and that labels must be unique.  This is some what a hinderance with the ad-hoc module.  As over time we all know that data changes and if we can’t update the report model without breaking the ad-hoc reports built in report builder then what good is it?  Any suggestions or help would much appreciated.

  2. Almost every post I made about Report Builder, be it the pros and cons of creating a report model on