Order of columns using drillthrough

I need to implement drillthrough options in a cube using MSAS 2000.
But required a given order of columns for showing these columns and I
don't know how can I set an order of columns.
It looks like I can only select and deselect column outputting but
there is no possibility to set an order.
Thanks for help,
AndriyOn Jul 9, 3:40 pm, andr...@.rambler.ru wrote:
> I need to implement drillthrough options in a cube using MSAS 2000.
> But required a given order of columns for showing these columns and I
> don't know how can I set an order of columns.
> It looks like I can only select and deselect column outputting but
> there is no possibility to set an order.
> Thanks for help,
> Andriy
The only way I know is to edit the MDX directly - IDE editor doesn't
allow to set the order.
Marco

Order of columns using drillthrough

I need to implement drillthrough options in a cube using MSAS 2000.
But required a given order of columns for showing these columns and I
don't know how can I set an order of columns.
It looks like I can only select and deselect column outputting but
there is no possibility to set an order.
Thanks for help,
Andriy
On Jul 9, 3:40 pm, andr...@.rambler.ru wrote:
> I need to implement drillthrough options in a cube using MSAS 2000.
> But required a given order of columns for showing these columns and I
> don't know how can I set an order of columns.
> It looks like I can only select and deselect column outputting but
> there is no possibility to set an order.
> Thanks for help,
> Andriy
The only way I know is to edit the MDX directly - IDE editor doesn't
allow to set the order.
Marco

Order headers and lines

Hi,

I am trying to design a data mart that will server as a data source for an Analysis cube. I would like to know the best practice for handling order headers and order lines. Do I need 2 fact tables in the data mart, and does there need to be a foreign key relationship between them.

The header table will contain information like whether a delivery was made on time, which depot delivered the order, how many times the delivery was attempted, total distribution charge, whereas the line table will contain product related information with quantities ordered / delivered, and the cost per line

Thanks

Depends on the analysis that needs to be supported, both by the data mart and the cube. For example, the FactInternetSales and FactResellerSales tables in the sample Adventure Works DW database are at the line level. But from your description, it sounde like there are relevant measures at both the header and line item level, so 2 fact tables (with 2 mesure groups) may be preferable. The detail table would then have a foreign key for the parent header table.

In terms of dimensions, those which directly relate to the detail measure group can be configured with a "many-many" relation to the header measure group (using the detail measure group and header fact dimension as intermediates). And those dimensions which directly relate to the header measure group can be configured as "referenced" (via the header fact dimension) for the detail measure group.

This article argues for a single detail-level fact table, but the AS 2005 modelling features may mitigate some of these issues:

Managing Your Parents

Be mindful of reporting needs when designing parent and child fact tables

By Ralph Kimball

...

Oracle OLEDB and dates not matching

I have a ssas2005 cube built from data in an oracle data warehouse. The Time dimension has begin week dates as a key and joins to the fact table Week Begin Date field. Both are built in the dsv using named queries. The cube built fine until we changed the provider to the Oracle provider for OLEDB. Now the cube build is giving an error : "The attribute key cannot be found: Table: Fact_x0020_Service_x0020_Level, Column: WEEK_BEGIN_DATE, Value: 7/3/2005." on the first record. The dates look the same and the properties look the same. I tried converting the dates to character in the queries and the cube builds - but I have a lot of data missing. We changed the provider because of internal rounding problems throwing the numbers off. Why is this happening? Is there a way to fix this?

The answer is trivial but situation overall quite confusing.

The implementation of OLEDB providers to the same relational datbase varies quite a lot. The changes in functionality happen from one version of OLEDB provider to another, the differences are even greater between OLEDB providers implemented by different companies.

In short: You could think that changing OLEDB provider in the conneciton string is a trivial, but in the reality it is not so at all. If this is absolutely neccessary that you use another OLEDB provider, you should work through every processing error.

Hope that helps

Edward Melomed.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||I've been able to resolve all the problems but the date. It seems the issue is in the internal representation of the date between the .Net provider and SSAS - and there's no way i know of to fix the problem without converting the date to some other format - which causes other problems down the line with my date functions. Anybody have an idea on getting around this?

Oracle OLEDB and dates not matching

I have a ssas2005 cube built from data in an oracle data warehouse. The Time dimension has begin week dates as a key and joins to the fact table Week Begin Date field. Both are built in the dsv using named queries. The cube built fine until we changed the provider to the Oracle provider for OLEDB. Now the cube build is giving an error : "The attribute key cannot be found: Table: Fact_x0020_Service_x0020_Level, Column: WEEK_BEGIN_DATE, Value: 7/3/2005." on the first record. The dates look the same and the properties look the same. I tried converting the dates to character in the queries and the cube builds - but I have a lot of data missing. We changed the provider because of internal rounding problems throwing the numbers off. Why is this happening? Is there a way to fix this?

The answer is trivial but situation overall quite confusing.

The implementation of OLEDB providers to the same relational datbase varies quite a lot. The changes in functionality happen from one version of OLEDB provider to another, the differences are even greater between OLEDB providers implemented by different companies.

In short: You could think that changing OLEDB provider in the conneciton string is a trivial, but in the reality it is not so at all. If this is absolutely neccessary that you use another OLEDB provider, you should work through every processing error.

Hope that helps

Edward Melomed.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||I've been able to resolve all the problems but the date. It seems the issue is in the internal representation of the date between the .Net provider and SSAS - and there's no way i know of to fix the problem without converting the date to some other format - which causes other problems down the line with my date functions. Anybody have an idea on getting around this?