SQL Server 2008R2 function in question: ( SELECT ( STRTOMEMBER(@FromDateShippedMonth, CONSTRAINED) : STRTOMEMBER(@ToDateShippedMonth, CONSTRAINED) ) ON COLUMNS FROM This parameter set does NOT trigger the error: @FromDateShippedMonth = [Date Invoiced].[Month].&[2012]&[1]&[1] @ToDateShippedMonth = [Date Invoiced].[Month].&[2012]&[4]&[12] This parameter set DOES trigger the error: @FromDateShippedMonth = [Date Invoiced].[Month].&[1900]&[1]&[1] @ToDateShippedMonth = [Date Invoiced].[Month].&[1900]&[4]&[12] Only the year 1900 triggers the error. Any idea WHY????

Hey John, Do you have the member for December 1900 (@ToDateShippedMonth) in your date dimension in your cube? This error could be due to not having it there. You dont really need the CONSTRAINED flag unless you feel a real need for that. To elaborate more on the above mentioned, the MSDN documentation states - "When the CONSTRAINED flag is used, the member name must be directly resolvable to a qualified or unqualified member name. This flag is used to reduce the risk of injection attacks via the specified string. If a string is provided that is not directly resolvable to a qualified or unqualified member name, the following error appears: "The restrictions imposed by the CONSTRAINED flag in the STRTOMEMBER function were violated." HTH. Cheers, IceQBPlease mark correct answers :)

I use 01/01/1900 for anything that comes into the cube missing a date...so it is in the date dimension. I can select it from the parameter dropdown list. The parameter strings are created programatically with a bit of custom code. DateKey Date Year Month Day Quarter 0 1900-01-01 00:00:00.000 1900 1 1 1 19800101 1980-01-01 00:00:00.000 1980 1 1 1 19800102 1980-01-02 00:00:00.000 1980 1 2 1 Perhaps the DateKey of 0 has something to do with it. I didn't know you didn't need the CONSTRAINED flag. I started with the MDX Microsoft creates when you drag and drop and moved on from there. I've never found a good resource for MDX education. When I removed the CONSTRAINED flag, the error doesn't appear but the data is NOT filtered by year either.

Oh ok... Can you clarify if you get data, but not filtered by the year or if you don't get any data at all.. From the MDX snippet you have provided, its hard to make out if its the main select of your query or a sub cube. I dont want to make much assumptions here in trying to guess why the data is not filtered by the Year, but one thing that seems a little strange to me is the value set to the @ToDateShippedMonth parameter ( [Date Invoiced].[Month].&[1900]&[4]&[12] ). Do you have December 1900 in your date dimension? In the table of sample data you provided in your previous mail, I see that after 1900/01/01, the next member is 1980/01/01. Try running your query for the following parameters and see if you get data: @FromDateShippedMonth = [Date Invoiced].[Month].&[1900]&[1]&[1] @ToDateShippedMonth = [Date Invoiced].[Month].&[1980]&[4]&[12] Also, there are plenty of good books there for learning MDX. http://social.msdn.microsoft.com/Forums/en-US/sqlanalysisservices/thread/9fe5efb1-7256-4874-865c-96cf6795cd91. My personal favorite is the one by Chris Webb and Shivakumar Harinath - MDX solutions... Helps you master the language from ground up. HTH. Cheers, IceQBPlease mark correct answers :)

IceQB...I think you may be onto something...I do NOT have 12/1900 in my dimension. I have a different problem with the date filter not being applied when running from http (different thread). While I was testing for that problem I decided to run the year 1900 and got this error. So I should probably add 12 months from 1900 to my date dimension. That should fix this problem.... And I'm back to my original, more difficult problem. I'll change the dimension, process the cube and get back to you.

IMHO - its not a good idea / right approach to have any members in the 1900 year other than 1900/01/01. That's not the correct way of solving the problem. The reason you need 1900/01/01 is because any NULL dates default to this one, and then there are not going to be any records with dates that fall in 1900 or 1901 (unrealistic dates) greater than 1900/01/01. If you happen to have records for the year of 1900 (other than 1900/01/01), then you should not solve that by adding members to your date dimension, but should be cleaning up your data to get rid of these dates and categorize them under the UNKNOWN member. HTH. Cheers, IceQBPlease mark correct answers :)

You are correct...I decided against that. I'm trying to solve my other problem and not concentrating enough. I will have a secondary problem if a user decides to select 1900 for a report - the report will "try" to show 1/1900 - 12/1900. I'll have to filter1900 out of the dataset that builds the parameter list. Thanks again...I've had some thoughts on my original problem so I'm going to start a new thread...I think I have a user permission problem....somehow users can run a report bur are prevented from sending parameter data back to the report so everything is showing up as if "all" had been selected.