SSRS: the right
reporting solution

We are 100% committed to Microsoft SQL Server Reporting Services (SSRS) as our reporting tool.
It is a great tool which has become a standard
for many medium to large companies.

Often these companies will have internal
resources that have the skill set to write their own reports should they feel the need to do
this internally.

Be aware of the disadvantages

However SSRS isn’t without its’ downside. The major disadvantage for us as a supplier of a product that is used across many customers is minimising the associated deployment issues that might otherwise arise using vanilla SSRS concepts. This is particularly so when there are many TimeFiler users/employees, and the various reports (most of which will derive from standard reports) that will be needed, and the employee security that needs to be observed.

Our approach

So we have taken the approach that although SSRS will process the information and render it, TimeFiler will take responsibility for asking the report parameters, respecting its own application security, and showing the results. This has made it a lot more manageable if we don’t need to bring NT security into the mix just to generate a report as TimeFiler is already well aware of employee / manager security requirements.

There is a huge amount of integration going on
to the point where any of our views within TimeFiler (and typically the Manager Views),
can be printed out to PDF, or Excel without a single line of SSRS reporting ever needing to be written. We have invested a lot of time in being able to render most of views into the format
that is native SSRS (called an RDL), which SSRS
can then generate reports from. This all happens
behind the scenes automatically, and we know how costly these kinds of reports would be if they were to be ‘manually written’ for each customer. These are costs you will never have to pay.

Why our approach works

We like presenting and distributing the information within TimeFiler, because between the different SQL Server Editions, and the different SQL versions, there are wide differences in what SSRS functionality is supported. And Microsoft being Microsoft, it leans towards its own products. So for example the rendering of a report to HTML has required our intervention prior to it being shown, because the standard SSRS rendering does not do a great job with FireFox, or other non-IE browsers.

Simplifying the process

Most of our reports can be ‘written’ by configuring grids (such as deciding the fields, and order; sorting and grouping, for example) within our accompanying Studio configuration application. This makes the production of reports a piece of cake and for the most part this avoids having to actually write a SSRS report in the traditional way. However there is the freedom to then extend the report within Microsoft Visual Studio if there is specific extra functionality needed (charts and cross tabs spring to mind).

D.I.Y. reports

And of course there is nothing stopping you from writing your own SSRS reports from scratch, and then asking TimeFiler to render them much like any other reports. So in effect TimeFiler can become a launch pad for all your employee reports, and as TimeFiler knows about employee security, it can do a better job of handling that on your behalf than you could do with just straight SSRS. For example, deploy a report, and know that the that one report will respect employee security for every employee that runs it. And know that the report parameters being asked for will also respect security if they need to.

It couldn't be easier.

 

 

Ajax technology

Timesheets: income or overhead?

Try TimeFiler now

Enquire now

Newsletter sign-up