Report Model Formatting Not Propagated to Report
I have created a report model that contains a number of currency metrics. Within the model, I have set the format for these metrics as C0 meaning I want the value formatted as currency with no decimal places. When I use the report builder wizard to create a report, the Query Designer seems to recognize the desired format as it displays "$0" in the column field pane when I drag one of these metrics over. However, when the report is generated, the format attribute is not set and the report displays these as decimal numbers of the form ######.####. What can I do to make sure that the report is generated using the setting specified in the report model? I'm using Sql Server 2008 R2. Thanks.
May 11th, 2010 5:37pm

OK, I've verified this behavior on two different servers and also different data types. Whether for dates, percentages or currency, no formatting information in the model makes its way to the report. That is the purpose of the Format string specified on an attribute in a report model, is it not? What am I missing here? Is there some configuration setting I'm missing?
Free Windows Admin Tool Kit Click here and download it now
May 12th, 2010 3:00am

This issue persists. Once again, in my model, I have currency format C0 specified for fields of type decimal. For example, <SemanticModel ...> ... <Entity ...> <Attribute ID="G6786b1d5-8943-4b03-a2b5-58123ad17e2c"> <Name>Order Revenue</Name> <DataType>Decimal</DataType> <Width>15</Width> <Format>C0</Format> </Attribute> </Entity> ... </SemanticModel> And yet, when a report is created based on this model, the format is not applied to the value. I have to go into each column in the report and manually set the format to "C0". Based on my understanding of report models, this should not be necessary as the report should default to the format specified in the model. Could someone PLEASE provide some clarity here?
May 13th, 2010 4:36pm

At the risk of beating a dead horse, I must once again point out that the issue raised in my first post persists. Can anyone provide a simple explanation for the behavior that I am witnessing? Am I the only one in the world working with report models?
Free Windows Admin Tool Kit Click here and download it now
May 19th, 2010 11:14pm

This is indeed a very interesting conversation that I'm having with myself over the past couple of weeks, albeit a bit one-sided. What would be ideal is if someone from Microsoft that was familiar with the technology would respond to the very simple question initially raised in this thread. Until this happens, apparently, I must continue talking to myself. The premise, as I understand it, of a report model is to present a view of the data that is suitable for ad-hoc reporting purposes which, among other things, includes default formatting of the exposed fields. Is this true? If it is true then is there a trick to coercing the formatting defined in the model to propagate to report builder and other report construction tools? If this feature is not something the report model infrastructure supports, then why would the format property be available in the model? I want to define formatting for fields in the model. I want Report Builder to recognize this format and apply it to a wizard-generated report. Is this possible? If it is not possible, then what is the purpose of the Format property on a report model field?
May 21st, 2010 7:32pm

Since you mention the "wizard-generated report" and SSRS 2008 R2 I assume you are using RB3.0. RB2.0/3.0 provide full-featured report layout experience which does not make use of layout metadata defined in the report model, including the default field formatting. RB1.0 provides a model-centric experience that does make use of this information.
Free Windows Admin Tool Kit Click here and download it now
May 22nd, 2010 12:28am

Thank you for responding. That is, however, a very disappointing answer. One would think that as a technology matures, it would become more feature-rich to support a wider array of scenarios, not step backwards. This means that every time a user selects a currency field from the model and places it on the report they will be forced to manually reformat it - unless, of course, they are happing seeing .0000 all the time. I fail to understand why it was necessary to deprecate that feature. What good, then, is the Format property in the semantic model? Is it useful for anything at this point?
May 25th, 2010 4:21pm

Wow. We are having the same problem. We are using report builder 2. I just want to make sure that I understand correctly. Even though there are properties to set to format the field in the model, report builder 2 is not going to use these properties that we set?Kim B.
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2010 8:46pm

Yes, Wow. I spent countless hours trying to figure out what the problem was. Did I have something configured incorrectly? Was there something somewhere I needed to turn on? As is evident from this post, it took over a week of badgering to get somebody from MS to even RESPOND to the basic question of why formatting information was not propagated from the model. Perhaps nobody responded sooner because the answer was rather embarrassing: something that used to work no longer does. What even more troublesome is that making this work (like it is supposed to/ used to) would take very little effort to implement correctly. They have the report model in memory when the wizard is running; all they would have to do is pass along the format string (and other defaults) specified in the model to to RDL. This question is marked as "answered", but one (among many) question that remains is: If the format field, for instance, is not propagated to RB and other report-authoring tools, then why is it available for specification in the model? Again, as I asked in a previous post: What good, then, is the Format property in the semantic model? Is it useful for anything at this point? An even better question is When will the problem be fixed, if ever?
June 3rd, 2010 8:27pm

I'm sorry for the confusion around this and the delayed response... personally I try to monitor these forums at least once a week and I'm not sure how I missed this particular post. The background for this issue is that report models were originally designed for RB1.0 and nearly all of the capabilities of report models are exposed in the RB1.0 interface. When we built RB2.0 we decided to start over and address the dominant piece of feedback we received regarding RB1.0: that most of our customers were more interested in a full-featured stand-alone reporting client that could connect to any data source, rather than the RB1.0 experience limited to report models. In making this decision we hoped to include report model capabilities in RB2.0 as well, and we were able to include a query designer for report models but features to consume other model metadata (such as data format, column widths, default sorting, Clickthrough links, etc.) did not make it given our limited resource constraints. Stepping back from the resource practicality though, the RB2.0/3.0 interface is more complex and does not really target the low-end user that RB1.0 aimed for. Adding the model metadata features would be a nice convenience but doesn't really address the fact that RB2.0/3.0 is fundamentally more complex than the RB1.0 experience. Given this, we continue to ship RB1.0 with the expectation that most customers using report models are continuing to use RB1.0. Hopefully this addresses your questions. Why is format available in the model and is it still useful? It is there for RB1.0 which continues to use it. Will newer RB versions consume this metadata? Possibly--we're always welcome to customer feedback. To be honest, this is maybe the second time I've heard anyone ask about this. The best avenue for providing this type of feedback to the product team is Microsoft Connect which provides a formal mechanism for us to collect and respond to feedback.
Free Windows Admin Tool Kit Click here and download it now
June 4th, 2010 3:57am

Mr. Meyers, Yes this feature would be very useful to have put back in a future release. We are using report builder 2 and eventually will be using report builder 3 and any future releases that come out. We have some very savvy users but they prefer to use a model rather than sql. It would be extremely helpful to be able to already have fields formatted in the model for them rather than have them have to format the data on every single report that they build. Thank you, KimKim B.
June 10th, 2010 4:24pm

Thanks for the feedback, we will keep this as a request for a future release.
Free Windows Admin Tool Kit Click here and download it now
June 11th, 2010 1:23am

Mr. Meyers, Thank you for the full explanation. Another vote for future inclusion. It would be great if the format specified in the model we're then copied to the report at design time. Default formats are something our report writers expect and would use extensively. Our data frequently go to 4 digits when we want to display 2. We've got 500+ attributes so it is quite a disappointment to find this doens't work as expected under 2.0/3.0. Does the width property of the model attribute behave in the same way? That is, it works for RB 1.0 but not 2.0/3.0? I can't seem to get this to have an impact either. Thanks again, Michael Shewmaker
July 13th, 2010 8:35pm

> Does the width property of the model attribute behave in the same way? Nevermind, I rescind the quesion. I just reread your message and see that column widths, default sorting, etc. have all been excluded from 2.0/3.0.. These also would be useful to have in a future release. Thanks again for your earlier detailed reply.
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2010 8:44pm

I'd like to vote for this issue to be fixed ASAP as well. It is a shame that you took out this functionality in order to appease the masses, while alienating your core report model users. By doing so, you've made report models far less likely to be adopted by anyone. It's like report models are committing suicide.
December 1st, 2010 5:35pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics