THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Greg Low (The Bit Bucket: IDisposable)

Ramblings of Greg Low (SQL Server MVP, MCM and Microsoft RD) - SQL Down Under

SQL Server Reporting Services: Should support include files

This blog has moved! You can find this content at the following new location:

Published Friday, February 19, 2010 7:54 AM by Greg Low

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Siddharth Mehta said:

This concept makes a report very much like a server side page, like a .aspx page for example. In .NET structure as we have a .aspx page and code behind file, this concept looks similar to that. Also having this code in raw format means it would not be compiled but interpreted by the service at runtime and this opens a scope for performance issues. In my viewpoint, assembly is still the better way compared to what you propose, but I agree that a better way of developing and/or deploying the same should be facilitated from BIDS / Report Manager.


Siddharth Mehta

February 20, 2010 4:27 PM

Greg Low said:

Hi Siddharth,

It doesn't change the performance characteristics as you can already do this via the "Code" properties of a report. The difference is in managing those code areas.



February 21, 2010 2:11 PM

Dave J said:

The only issue with that solution is that whenever you changed the code, you would need to know which of the reports is using it so that you can redeploy them all.

Of course, the advantage of only having to maintain it in one place would almost certainly outweigh this, but having some way to determine which reports are dependent on a piece of 'shared code' would be a useful extension to your idea.

February 22, 2010 9:12 AM

Greg Low said:

I'm hoping the reports that depend on it would be the ones in the same project !



February 23, 2010 9:21 PM

Celebrim said:

There are probably implementation issues here.  

Essentially what you are asking for is the ability to deploy an assembly by simply uploading the code for it, as presumably that code would then be compiled into an assembly.  So now the question becomes, have you just evaded all the security and permission constraints that we (rightly) put on the execution and installation of a deployed assembly?

There are also issues like, "Is a shared variable in the global code shared by all the reports, or do we end up with a second copy of the assembly and whatever memory it demands for each report execution?"

In general, I'm ok with the idea, but I don't place it in it nearly as much value as things like being able to define styles that can be applied to report objects much like a style in HTML (css) or even MS Word.  And a global storage space for such styles would be even more useful.

October 19, 2010 3:15 PM

Leave a Comment


This Blog



No tags have been created or used yet.


Privacy Statement