Archive for March 2010
When browsing a cube using Excel 2007, you can drillthrough the measures to display up to 1000 rows of the transaction level source data.
I often get asked whether this limit of 1000 rows is configurable – well the good news is yes it is.
There is an option in the actions tab of the BIDS cube designer which allows you to specify the maximum rows, but helpfully this is ignored by Excel. Instead, you have to set it in Excel when you create a pivot.
Just click “Options” on the “PivotTable Tools” ribon, then in the “Change Data Source” dropdown click on “Connection Properties“. In this screen, just change the “Maximum number of records to retrieve” property.
Whilst designing a data warehouse for a banking client recently, I needed to calculate projected future loan payments (including breaking this down by interest and capital payments) for every customer throughout the life of the loan.
In Excel this is a pretty simple job, as Microsoft helpfully provide a number of functions to do just that (namely PMT, FV, IPMT and PPMT). In SQL Server however we do not have the luxury of having ready made functions, so I set about making my own.
Initially I coded them up as SQL Server functions, only to find that the internal rounding that SQL performs renders the results too inacurate to be usable. It was therefore necessary to write the functions in a C#, and wrap them up in a CLR library. SQL Server can then import them as scalar functions, to be used by any query that requires them.
To overcome this, the Purple Frog team have written a .Net CLR library which add four loan amortisation functions to SQL Server, which can be called from within a query as scalar functions, such as:
SELECT dbo.PMT(@APR/12.0, @Term, @LoanValue, 0, 0)
The functions provided are:
- PMT (The monthly payment of a loan)
- FV (The future value of a loan at a given month)
- IPMT (The interest portion of the monthly payment at a given month)
- PPMT (The capital portion of the monthly payment at a given month)
These are designed to mirror the parameters and results of the Excel functions, and have been written in C# using Visual Studio 2008, and tested against SQL Server 2008 Enterprise.
The functions perform surprisingly well; in tests I was able to calculate over 3 million monthly payments per minute, and that was on a relatively underpowered development server.
You can download the C# code, or the pre-compiled binary from the Frog-Blog download section.
For anyone interested in SQL Server, the unmissable SQL Bits conference is returning for round six. “SQL Bits – The 6th Sets” is being held in central London for the first time, and unlike previous conferences it will be for one day only on Friday 16th April 2010.
It’s being held as part of the SQL Server 2008 R2 release, also happening that week in London.
Registration is now open, you can find out more at the SQL Bits website.
We highly recommend the event, hope to see you there…
I’ve just read an interesting thread on the SQL Server Developer Center forum, regarding how to filter results. Specifically the difference in MDX between using a subselect
SELECT x on COLUMNS, y on ROWS FROM ( SELECT z on COLUMNS FROM cube))
or using a where clause
SELECT x on COLUMNS, y on ROWS FROM cube WHERE z
In a simple query they produce the same results, but what is the actual difference? You can read the full thread here, but to summarise Darren Gosbell’s response…
Using the WHERE clause sets the query context and consequently the CurrentMember. This then enables functions such as YTD and PerdiodsToDate to work.
Using a subselect can provide improved performance, but does not set the context.