ReportServer 3.0.3 patch 6003
We are pleased to announce that ReportServer 3.0.3 Release 6003 is available. In addition to Release Notes 3.0.3, you can see in the Release Notes which improvements were made, which new features have been added and which bugs have been fixed.
An upgrade manual can be found in the documentation area. Happy Reporting!
In this blog entry we would like to draw your attention to an important feature of ReportServer: Scheduling.
Scheduling in RS allows you to run reports (or scripts) automatically at a predefined time. The results can be either sent by e-mail or stored in a TeamSpace. For this purpose, we will provide a step-by-step guide to give you insight into this central functionality.
We will discuss four points:
Here we go.
ReportServer 3.0.3 patch 6002
We are happy to announce that the 3.0.3-6002 version of ReportServer is available. The patch release of RS fixes some bugs and improves conditional scheduling. For a list of all changes please refer to the release notes. The upgrade guide is available in the documentation area. Happy reporting!
We are happy to announce that version 3.0.3, after successful test completion, is now officially released.
We would like to give you a brief look at the following points:
You find more information in the release notes.
The 3.0.3 ReportServer release increases stability and fixes errors. In addition, various improvements as well as new features are introduced. Refer to the release notes for a complete list of changes.
Please download the latest beta release of ReportServer 3.0.3 here and the respective upgrade / installation guide here.
For questions and problems this forum can be used.
Your ReportServer Team
We are happy to announce the upcoming Version 3.0.3 of ReportServer. It is a maintenance and bugfixing Version. It will contain several bugfixes and library upgrades. This includes the Saiku OLAP client and Jasper Reports library amongst others.
We hope to finish development by the end of March, carry out the tests in April and start deployment in May.
Your ReportServer Team
In this episode of the Dynamic List series we discuss how IT can enhance the user experience by providing proper descriptions and default aliases for attributes. Read more…
ReportServer scripting is probably the most complex but also the most powerful tool offered by ReportServer. In our newest tutorial we provide an introduction into scripting and the most common use cases.
To the tutorial: Getting Started with Scripting
In early April, MariaDB‘s CEO Michael Howard announced the development of the MariaDB ColumnStore with the words: “We’re uniting transactional and big data analytics all together under one roof. It’s the same MariaDB interface, security, SQL richness simplifying management. You don’t need to buy specialized hardware. It’s one unified platform.” (Read the full story on CIO.)
MariaDB’s ColumnStore is not entirely new. In 2014, InfiniDB (formally Calpont Corporation) ceased operations but not before releasing their column store technology (called InfiniDB and which was based on MySQL) under an open source license. MariaDB’s ColumnStore is based on InfiniDB and as the release notes say “most of the MariaDB ColumnStore code is unchanged”. We should thus expect no real leaps in comparison to InfiniDB but on the other hand can look forward to hopefully quite a mature and stable first release. A few days ago, the MariaDB team released a first alpha for testing and this is exactly what we did.
Testing a database is quite a challenge, as there are bazillion different use cases that you might want to include in your benchmark. For example, a huge plus of MariaDB’s ColumnStore is that it is fully SQL compliant and, in particular, ACID compliant. One way to test the system would thus be in an OLTP setup with numerous concurrently running small transactions. A second route would be to look at the analytical quality and consider not small transactions, but possibly long running OLAP type queries. In very large setups you might look at the performance of database clusters whereas the majority of projects will probably use only a single database node. Once you have decided on a certain test setup there is, of course, the question of how to measure the performance of the setup as this highly depends on the environment (what machine, how much RAM, disk speed, etc.). For this tentative test we decided to go the easy way: we have set up a single database node on a small virtual machine and used our analytics platform ReportServer to run a few OLAP type queries. We then did a comparative analysis and compared the performance of MariaDB’s ColumnStore against two other databases: the traditional MariaDB/MySQL InnoDB storing engine (to get a baseline) as well as the open source column store MonetDB.
The MonetDB column store has been around for quite a while (since 1993 according to their website) and is primarily developed at the Centrum Wiskunde & Informatica (CWI) in Amsterdam. While MonetDB is coming from academia (and admittedly has some quirks that you need to deal with) it has matured a lot in the previous years. In ReportServer it is supported as of version 3.0.
So in summary the setup is, MariaDB’s new ColumnStore vs. MonetDB (with MySQL InnoDB providing a baseline) on analytical queries within a restricted environment.