• 
• 

 1 of 2

Gallery

Automated printing of SQL Server Reports

Posted on 12 Jan 2010 at 15:13

Simon Jones wrestles with the printing of SQL Server Reporting Services Reports

The hardest part in implementing this solution was to generalise my new ServerReportPrintDocument class so that it would work with whichever report, and with whatever parameters, was to be printed. I got around this by making the class take a parameter that was a Delegate to (the address of) a method in my main application. A Delegate is just a Sub or Function definition with no body code of its own: you then define any number of other Subs or Functions that conform to the definition of this Delegate by having the same number and type of parameters, in the same order.

You can then pass the address of one of these Subs or Functions to any other Sub or Function that accepts a parameter of the Delegate type, to provide it with its run-time action. So I could create a new instance of this class, and then pass it the address of a method it should call to fill its particular report.

The class exposes just one property, a standard PrintDocument, which has its own Print method or else can be passed to a PrintPreview window to be shown to the user. Just one extra important feature was required, and that was to make my class implement the IDisposable interface so that it would tidy up when it was no longer required by disposing of its PrintDocument, its list of MemoryStreams and its ReportViewer.

If it didn’t do this properly these objects would hang around for longer than necessary, taking up memory and slowing the computer down (or worse).