Welcome to MSDN Blogs Sign in | Join | Help

CUBE Functions 3: Formula AutoComplete revisited

Previously when discussing CUBE functions, I showed a couple of examples of reports based on OLAP data that could be built using CUBE functions.  Now I’d like to explain how we’ve done something very special with Formula AutoComplete to make it easy to navigate the OLAP namespace while authoring CUBE functions.

Formula Auto-Complete for CUBE function arguments
Formula AutoComplete for CUBE function arguments has some special behaviours relative to the other functions in Excel.   As a brief refresher, Formula AutoComplete is a feature that provides a list of values from which to choose as you write formulas … here
is a blog post that describes this in detail.  In most Formula AutoComplete scenarios, Excel knows the list of values (formulas, named ranges, table names) that it should display because those values are part of the Excel application.  For example, when you start typing a function name, Excel can give you a list of all the other functions that start with the same character(s), as is shown in this screenshot.


(Click to enlarge)

In this case, Excel already knows what all the possible function names are that begin with “s”, so it can easily display a list of function names that begin with the specified character(s).  Ditto named ranges, UDFs, table names, etc. 

For many arguments to the new CUBE functions, however, we have a different scenario.  Excel does not inherently know about the multi-dimensional database (OLAP cube) from which data is being fetched.  In order to provide an auto-complete dropdown, it is necessary for Excel to query the multi-dimensional database or OLAP cube to find out what the set of valid items will be.  Here’s an illustration of how this works.  In this example, I have already created a connection named “Adventure Works” to the Adventure Works database on SQL Server 2005 Analysis Services.

I will start by entering a CUBEMEMBER function that uses the Adventure Works connection, and when I get to the second argument, (which calls for a member_expression,) I will only enter the opening quotation marks that tell Excel I am planning to enter a string.


(Click to enlarge)

The list of possible values that appear in the dropdown did not come directly from Excel.  How’d that work?  Excel issued a query to the Adventure Works OLAP cube and displays a list of dimension names from that cube.  Let’s say that I choose the Dimension named “Customer” and then enter a period (which is used as a separator by the MDX language).


(Click to enlarge)

I see that there are several hierarchies in the Customer dimension.  Using the arrow and tab keys, I will select the “Customer Geography” hierarchy and enter another period.


(Click to enlarge)

The auto-complete drop down shows me that there is a single member at the top of the Customer Geography hierarchy, and that item is “All Customers”.  By choosing this item and entering another period, I will see an auto-complete drop down of the children of “All Customers” (which are the countries in which the customers are located).


(Click to enlarge)

At any point, I can finish the argument by entering the closing quotation marks.

The key point that I want to make here is that the Formula AutoComplete feature is providing a mechanism for users to navigate the hierarchies in the multi-dimensional database.  Even if you have no prior knowledge of the multi-dimensional database to which you are connecting, Excel’s Formula AutoComplete feature will show you the dimensions in the cube, the hierarchies in each dimension, and the members (and their children and grandchildren, etc.) that are contained in each hierarchy.  Also, it can be much faster to use auto-complete to enter CUBE functions into Excel formulas because you only need to identify the item you want from a drop-down list and then hit the Tab key, as opposed to typing the full MDX name for each function parameter.

The name that you get for a member using Excel’s auto-complete will be a fully qualified name because you make a selection at each level of the hierarchy.  It is not the only name that could be used, nor is it the special “member unique name” for a member in the cube.  When you know that a shorter MDX expression will resolve to the same member, you are free to enter the shorter expression.  It’s just that Excel will help you to navigate the namespace of your database when you’re not already familiar with that data.

The list of items that is displayed in each case is the list of the first fifty (50) items which match the characters that have been entered so far.  As you enter more characters, the auto-complete drop down list is automatically updated.

This is a feature I love to demonstrate – for folks that use Analysis Services cubes, it really is going to be a very helpful feature.

Next time, I’ll talk a bit about the work we’ve done in Excel 12 to make connection management easier.

Published Thursday, February 09, 2006 4:00 PM by David Gainer

Comments

# re: CUBE Functions 3: Formula AutoComplete revisited

Friday, February 10, 2006 4:23 PM by Kory
You might cover this (or already have): Will Excel 12 allow submitting a direct MDX statement?  How about support for Actions (including DrillThrough)?

Thanks

Kory

# re: CUBE Functions 3: Formula AutoComplete revisited

Friday, February 10, 2006 10:36 PM by David Gainer
Hi Kory

Yes to actions, no to direct MDX statement.  See previous post for full support of Analysis Services.

# re: CUBE Functions 3: Formula AutoComplete revisited

Sunday, February 12, 2006 8:34 PM by Harlan Grove
Has anyone noticed that when the topic involves Excel and servers the number of comments drops considerably compared to general spreadsheet functionality? Could this be a sign that Microsoft has found a new 80/20 rule: 80% of development effort spent adding features that in blissfully optimistic estimates may be used by at most 20% of users?

# re: CUBE Functions 3: Formula AutoComplete revisited

Sunday, February 12, 2006 9:25 PM by Paul
Harlan is right, historically, but I think there is a lean towards advanced usage of Excel in the mainstream now.

# re: CUBE Functions 3: Formula AutoComplete revisited

Monday, February 13, 2006 10:05 AM by Jonathan Cooper
I think that Excel has become so popular, that the general knowledge base and usage of Excel will continue to escalate towards the more advanced functions.

With this particular post, I can not get the screen shots to show.  Anyone else having this same problem?

# re: CUBE Functions 3: Formula AutoComplete revisited

Tuesday, February 14, 2006 12:34 PM by John Greenan
Any chance of some info on what's going on with VBA, COM AddIns and so on???

# re: CUBE Functions 3: Formula AutoComplete revisited

Tuesday, February 14, 2006 2:42 PM by Harlan Grove
Jonathan Cooper wrote...
>I think that Excel has become so popular, that the general
>knowledge base and usage of Excel will continue to escalate
>towards the more advanced functions.

Begging the question whether this is a good thing or not. I agree that Excel is getting more use, but it's either used by programmers who don't really understand spreadsheet design or by nonprogrammers who don't understand software engineering at all. The usual result is bloated workbooks that are already a nightmare to maintain. Excel 12 will boost that nightmare a few quanta.

# re: CUBE Functions 3: Formula AutoComplete revisited

Tuesday, February 14, 2006 3:17 PM by David Gainer
John,

There has not been significant change in the VBA IDE.  We have added all the new capabilities to Excel's OM.

At a later point, I will have some other programmability posts.

# re: CUBE Functions 3: Formula AutoComplete revisited

Wednesday, February 15, 2006 12:04 AM by Damon Longworth
Jonathan and Harlan

Both points are valid, although I must take exception with Harlan's generic categorization of spreadsheet users.

There are many users who fall into both categories, but there is a growing community of Excel developers who are aware of Excels capabilities and constraints. I too, share your concern about bloated files with Excel 12 and some of our users.

In my opinion, we need to promote Excel as a development platform and educate the user community. They need to know about efficient spreadsheet design, along with the appropriate applications for Excel.

Damon Longworth
www.ExcelUserConference.com

# re: CUBE Functions 3: Formula AutoComplete revisited

Wednesday, February 15, 2006 4:14 PM by Harlan Grove
Damon Longworth...
...
>In my opinion, we need to promote Excel as a
>development platform and educate the user
>community. They need to know about efficient
>spreadsheet design, along with the appropriate
>applications for Excel.

What's an appropriate application for Excel?

For ad hoc financial or what-if (aka decision support) analysis, Excel is as good as APL and its offspring, but that's the sort of application for which development is pointless since it's next to impossible to predict all the variations.

For repetitive tasks, there are usually better systems. Report generation is usually better done in Access than Excel. Some may misperceive the oh, so wonderful new rainbow effects available in Excel 12 as a benefit. Most of the people who use them will succeed in reaching new levels of ugliness.

For formal analysis, even exploratory data analysis, most stats packages are better than Excel. Since it appears the DATP isn't up for revision beyond stripping off its udfs, it'll still provide only lightweight functionality.

As for the user community, what do you believe it is? Two groups: users and developers? Users being the people who 'use' Excel only insofar as they need it to run the models built by the developers? And these developers, who are presumably familiar with web services, managed coding, etc., will have how much experience *using* spreadsheets in order to inform their design decisions?

I work for a company that employs hundreds of developers of all sorts and a few dozen of whom work with Excel and FormulaOne. Without exception, the in-house systems that avoid using Excel or FormulaOne are easier to use, faster, and less crash-prone. Why's that? Maybe the 'Excel developers' are the less competent ones. That's not going to change any time soon.  Also, Excel's event handling is crude.

Finally, if Excel is really meant to be used for REAL APPLICATION DEVELOPMENT, it's time to provide much greater granularity in recalculation (different calc settings, auto vs manual, in each open workbook at least), simultaneous background execution of macros in one workbook and interactive use of other open workbooks (this can be kludged using multiple Excel instances), and augment workspaces so that they can have VBA modules and their own events that could apply across all open workbooks in the same way, e.g., SheetChange applies across all worksheets in a workbook.

Why stop there. Until Excel provides true 3D referencing, like @INDEX(A:A1..D:X5,1,2,3) to refer to cell C:B3 as provided by 123 as well as relative worksheet referencing, most models built using Excel will involve lots of kludges.

The reason there's so much traffic in the Excel newsgroups isn't that there are thousands of Excel users pushing the development envelop. Read the postings. It's because most Excel users are novices building their own ad hoc models or (mis)using Excel to generate reports, and few seem to be able to read online help. This is your future developer base. And you don't see any problems?

I may have a distorted view. To me spreadsheets are tools for performing calculations, a branch of applied math. Spreadsheet formulas are not the ideal means of expressing mathematical relationships, especially not for recursive relationships that can't be expressed as array formulas. Procedural languages may be no better, but there are other alternatives. Lotus Improv in the past and Quantrix currently provide much better means of expressing relationships. MDX may also. And they provide true multidimensionality.

Spreadsheets generally and Excel in particular have been widely and throughly misused over the last two decades. Excel 12 will exascerbate the problem. You may respond that it's the user's choice, but that choice is all too often made out of ignorance of alternatives. Excel 12 will make the situation worse.

When things go wrong (and they will), I'd prefer going through thousands of lines of structured procedural code than thousands of cell formulas.

# re: CUBE Functions 3: Formula AutoComplete revisited

Wednesday, February 15, 2006 7:25 PM by David Gainer
Hi Kory (again)

I'd like to further clarify my answer to this question: "Will Excel 12 allow submitting a direct MDX statement?"

We don't support sending an MDX query such as: SELECT {[Customer].[Customer Geography].children} ON 0 FROM [Adventure Works]

We do however support arbitrary MDX expressions within the CUBESET function as long as those expressions resolve to a set.  For example, when we say: =CUBESET("Adventure Works", "[Customer].[Customer Geography].children", "Countries") we have used this MDX expression as the second argument: [Customer].[Customer Geography].children  

In a similar fashion, any MDX expression that resolves to a member can be used as an argument to the CUBEMEMBER function.

So we do support sending MDX expressions to Analysis Services for evaluation, but we don't support arbitrary MDX queries.

I hope this clarifies what was meant by my previous response to this question.

# Microsoft Excel : CUBE Functions 3: Formula AutoComplete revisited

Saturday, May 31, 2008 5:03 AM by Dating

Previously when discussing CUBE functions, I showed a couple of examples of reports based on OLAP data that could be built using CUBE functions. Now I’d like to explain how we’ve done something very special with Formula AutoComplete to make it easy t

# Microsoft Excel : CUBE Functions 3: Formula AutoComplete revisited

Thursday, June 05, 2008 3:43 PM by Weddings

Previously when discussing CUBE functions, I showed a couple of examples of reports based on OLAP data that could be built using CUBE functions. Now I’d like to explain how we’ve done something very special with Formula AutoComplete to make it easy t

New Comments to this post are disabled
 
Page view tracker