New Drillbridge Plus feature: fetch attributes!

Drillbridge Plus has recently gained a new feature at the request of a customer. This one is kind of interesting and required a bit of deep thinking in terms of the best way to architect it. Here’s the deal: Smart View will let you drill-through on a data value where your grid is using attribute dimensions, but it won’t pass the attribute associations as part of the request. And as it turns out, there are instances where it’d be useful to have that attribute member so you can use it to dial in the SQL query that Drillbridge creates and executes.

What to do? Ask Drillbridge to go fetch those attribute member values for you anyway! In this post I’m going to walk through a use-case showing off the new feature, how to set it up, and I’m also going to show off some recent debugging enhancements that are really useful and have been around for awhile.

Let’s start. First, consider a normal Drillbridge report definition with a simple query:

A normal Drillbridge report definition (before adding attributes)

Continue Reading…

People really hate VBA

Stack Overflow did a really great article on the most disliked programming languages that I thought was really interesting, with my own little Essbase twist on it. On Stack’s jobs site, they let people specify which technologies they’d rather not work with. Tops on the list are Perl, Delphi, and VBA. PHP and Objective-C are next but they don’t have near as much dislike as the top three.

So, why all the hate? To me, these all have intuitive explanations, and at least in the case of Perl and VBA, I think it has to do with the context in which “projects” with these technologies occur. Perl and VBA are frequently used as quick and dirty scripting languages to automate some process. And often these one-off automation solutions tend to grow. I could be charitable and say that these solutions grow “organically” but it’s probably more often the case that they grow haphazardly – which is perhaps also being charitable.

I think people are indicating they dislike these languages because they just don’t want to work on them and don’t have good experiences working with their sprawling, complicated, hard to debug, and incredibly sparsely documented codebases. Briefly, and skipping down the list to Objective-C, I think that’s indicated as disliked mostly because it is “out of favor” with respect to the Swift programming language. The iOS ecosystem is incredibly fast-paced and people seem to need to aggressively keep their skills fresh.

As it pertains to Essbase, I couldn’t help but think of my own corporate and consulting experience when it comes to VBA solutions. I can’t tell you how many times I got a call because there was a problem with some workbook that had some VBA code on it. It can be incredibly frustrating (and in the case of bringing in a consultant, expensive) to debug, fix, and enhance these solutions.

Quite simply, while the VBA-based solutions provide something valuable (automation, saved time, etc.) they become an absolute albatross in finance departments and make upgrades/migrations just that much more difficult. That’s one of the reasons that I think Dodeca is such an effective solution in numerous cases where VBA was used, because many of the things you needed VBA code for are just inherent features of the product, with zero code at all.

For example, without a single line of code, Dodeca can connect to Essbase, pull members from an outline and present them as dynamic selections to users, retrieve multiple cubes into multiple ranges on multiple tabs in a workbook, send data back to Essbase, and run calculation scripts. These are features that typically make up pages and pages of low-quality, low-value VBA code and often necessitates the continued usage of the old, unsupported classic add-in.