{"id":283,"date":"2005-08-04T01:34:47","date_gmt":"2005-08-04T07:34:47","guid":{"rendered":"http:\/\/jameskovacs.com\/2005\/08\/04\/Digging+Deep+Into+Reporting+Services"},"modified":"2005-08-04T01:34:47","modified_gmt":"2005-08-04T07:34:47","slug":"digging-deep-into-reporting-services","status":"publish","type":"post","link":"https:\/\/www.jameskovacs.com\/index.php\/2005\/08\/04\/digging-deep-into-reporting-services\/","title":{"rendered":"Digging Deep into Reporting Services"},"content":{"rendered":"<p><P>I was asked recently by a colleague whether you could programmatically emit the name\/value pairs of parameters in a Reporting Services report without hard-coding them.&nbsp;Seems like a logical thing to do. So I started digging deep into the guts of the Reporting Services object model and was sorely disappointed. I really like Reporting Services, but the object model accessible from within a report just bites. Let me explain.<\/P><br \/>\n<P>When you access Parameters in a report from the Report Properties&#8230; Code&#8230; (or a custom assembly), you are actually dealing with a Microsoft.ReportingServices.ReportProcessing.ReportObjectModel.Parameters object. (The class is located in an assembly Microsoft.ReportingServices.Processing.dll, which is installed by default in C:\\Program Files\\Microsoft SQL Server\\MSSQL\\Reporting Services\\ReportServer\\bin\\.) This object exposes a string-based&nbsp;indexer and that&#8217;s it!<\/P><br \/>\n<P><SPAN style=\"FONT-SIZE: 11px; COLOR: black; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\"><SPAN style=\"FONT-SIZE: 11px; COLOR: blue; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">public<\/SPAN> <SPAN style=\"FONT-SIZE: 11px; COLOR: blue; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">class<\/SPAN> Parameters {<BR><SPAN style=\"FONT-SIZE: 11px; COLOR: blue; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">&nbsp;&nbsp; public<\/SPAN> Parameter <SPAN style=\"FONT-SIZE: 11px; COLOR: blue; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">this<\/SPAN>[<SPAN style=\"FONT-SIZE: 11px; COLOR: blue; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">string<\/SPAN> key] {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; get {<BR><SPAN style=\"FONT-SIZE: 11px; COLOR: green; FONT-FAMILY: Courier New; BACKGROUND-COLOR: transparent\">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/\/ code<\/SPAN><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<BR>&nbsp;&nbsp; }<BR>}<\/SPAN><\/P><br \/>\n<P>You have to know the key (a.k.a. name of the parameter) to retrieve the parameter to get its value. There is no collection support. (i.e. No Count property and integer-based indexer or IEnumerable implementation.) Parameters is derived from System.Object rather than System.Collections.CollectionBase or something equally useful. You cannot use &#8220;foreach&#8221; or &#8220;for&#8221; to enumerate through the parameters.<\/P><br \/>\n<P>So from within a report, you cannot obtain a parameter list programmatically as far as I can tell. The same applies to ReportItems and Fields. You&#8217;re really limited to creating little helper functions rather than being able to programmatically query the state of a report. How disappointing!<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"<p>I was asked recently by a colleague whether you could programmatically emit the name\/value pairs of parameters in a Reporting Services report without hard-coding them.&nbsp;Seems like a logical thing to do. So I started digging deep into the guts of the Reporting Services object model and was sorely disappointed. I really like Reporting Services, but [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[],"class_list":["post-283","post","type-post","status-publish","format-standard","hentry","category-reporting-services"],"_links":{"self":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts\/283","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/comments?post=283"}],"version-history":[{"count":0,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/posts\/283\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/media?parent=283"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/categories?post=283"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jameskovacs.com\/index.php\/wp-json\/wp\/v2\/tags?post=283"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}