Using OfficeWriter‘s integration with SSRS in conjunction with the Designer is typically a straightforward process with no programmatic manipulation of the reports. A developer designs the report in Visual Studio BIDS, opens the .rdl using the Designer, designs the template in Word/Excel, and publishes the report. The report is then rendered inside the Report Manager using the custom OfficeWriter export option. However, there are times that situations call for post-processing the report programmatically and that’s where the ExcelApplication and WordApplication objects come in. Accessing and rendering the reports through the SSRS API is straightforward and the resulting byte array can be turned into a MemoryStream and passed to OfficeWriter.
Adding the SSRS Web Service
The first step necessary to tapping into the SSRS API is to add the Report Execution Service to your web references inside of Visual Studio. The URL for the web service is likely along the lines of *http://localhost/reportserver/reportexecution2005.asmx*, where localhost/reportserver is the hostname and virtual directory of the SSRS server. Note that this is for SQL Server 2008, despite the 2005. This web service is located in the directory C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer in the example instance I am using. Continue reading Post-Processing SSRS Reports using OfficeWriter in .NET
[Image via Patou Fine Art]
Recently, I encountered a situation where I had to join two Data Tables from databases on two different servers. Had they been on the same server, I would do this in SQL with a simple JOIN statement, but since the databases were on different servers, my options were limited. I could:
- Use a linked server (http://msdn.microsoft.com/en-us/library/ms188279.aspx)
But: This wasn’t really an option because I wouldn’t be able to modify production servers
- Use System.Data and create a DataRelation
But: DataRelations are clunky and don’t perform LEFT OUTER JOIN’s very well
- Create a new DataTable and copy rows over manually (with, for example, a foreach loop)
But: This would be painfully slow
And: I’d have to duplicate a lot of null-row handling logic that LINQ and SQL do themselves
- Join the tables in the codebehind using C#’s own SQL-like syntax, LINQ.
But: I had no idea how to use LINQ.
After some research, I decided on option #4. To get a basic overview of LINQ, I started by going through 101 LINQ Samples and trying to learn the LINQ syntax. This was my first attempt at getting a method to join two DataTables: Continue reading Joining DataTables in LINQ
The following error is returned while attempting to install OfficeWriter 3.9 or below:
The System appears to have .NET 2.0 and an unrecognized version of J#. Please install J# 2.0 if you wish to use ExcelWriter .NET or WordWriter.
Starting with version 4, OfficeWriter has been written completely in C# and no longer requires the J# runtime. However, customers installing version 3.x of OfficeWriter do need the J# runtime. The version of J# should match the installed version of the .NET framework.
Install the J# redistributable that matches the .NET framework that you are using in your application.
Note: Microsoft has not released a J# redistributable that matches .NET 4.0 framework. To use OfficeWriter with .NET 4.0, you will need to upgrade to OfficeWriter 4 or later.
Those of us working with relatively high-level languages spend most of our time able to blissfully ignore the mucky little details that go into making a program actually run. C# allows us to not think about allocating and freeing memory, for example, or how our strings are terminated. It’s all too easy to extend this willful blindness to other details, like how numeric types actually work. Can this variable ever have a fractional part? Yes? Double! No? Int! Can it be really big? Long! Done, sorted.
Recently I was writing some functions to do unit conversions. Specifically, I was converting between points (1/72 of an inch) and EMUs (1/914400 of an inch). Part of the point of EMUs is that you can use them for high-precision values without needing floating point arithmetic, so I was storing them in a long. The application in question deals with fractional points, so those went into a double. Now, what’s the largest positive point that we can convert into an EMU without any overflow? If we do a little math we see that there are 12,700 EMUs per point, so the obvious answer should be long.MaxValue / 12700.0, which comes out to a bit over 7.2E14. Excellent. However, if I turn that around and convert that many points back into EMUs, I get -9.2E18. Oh dear. Continue reading A loss of precision, but not a loss of magnitude