Two new types of selectors were added to the frontend: Interval calendars and suggest boxes.

Interval calendars allow to select a time-range (from date / to date) using the calendar known from the original calendar selector. The interval selector shows two calendars, on to select the start and one to select the end date of the interval.

The suggest box offers the user valid input options while he types into its text box. This is well known from other web 2.0 applications.

Selector groups can now be turned into popup selectors by setting their new property “Popup” to true. Popup selectors only appear as a small and space saving button. By clicking onto this button, the user can open or close the selector group and use its contained selectors.

One of the main features of the new version is the much easier handling of stores. Unlike before, where cubes could be converted into offline cubes by setting some properties and setting the wanted dimension into the offline state, the cubes now can contain one or more store. Each of this stores defines a number of contained dimensions and facts, whereby different stores can contain different combinations of dimensions and / or facts and there is no need to copy cubes for different combinations in future.

The configurations of stores with the Workbench became easier and more intuitive: Simply add a new store to a cube by using its context menu and add dimensions and facts to the new store by clicking onto it. The Workbench will now automatically do all needed settings for your, e.g. by loading the lowest level of a dimension if you want to roll it up.

The rebuilding of dimensions is now more connected to cubes than before. Everytime a dimension is rebuild, all stores being dependend on this dimension will be automatically also rebuild in the same transaction if the dimension has chaned. “In the same transaction” means, the user will not see changed dimensions and cubes before both are finally loaded and commited. The advantage of this new transaction model is, that cubes can no longer reach the “outaged” state if dimension changed and the cube was not scheduled to rebuild directly after.

The internal ToDo lists – which instantOLAP uses to determine where to load which result cell from – became much faster and less limited. The overall performance improvement is round about factor 2 when generating and resolving the list. And, because the new implementation nearly uses any memory, there is also no limit for the maximum size of ToDo lists from version 2.6. Therefore, the “query too complex” message, which appeared when building reports with too much cells, will no longer appear.