PackageID in Logging Provider

Is there a technical reason (I imagine the real reason is time) that PackageID wasn't included as a Logging Provider column to log? While you can still track this by doing some fun things like event handlers or self-joining, I would think from a usability perspective, you should avoid that altogether by just adding the column.

I added a suggestion here to vote on if anyone else agrees:

http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=e58141d5-859f-4941-a675-cb9352d85575

-- Brian

I'd rather have PackageName!!!

Mind you, one thing I do is dynamically set up the name of my log file using the following expression:

REPLACE(@.[System::PackageName], " ", ".") + (DT_STR, 4, 1252) DATEPART( "yyyy", @.[System::StartTime] ) + RIGHT("0" + (DT_STR, 2, 1252) DATEPART( "mm", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "dd", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "hh", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "mi", @.[System::StartTime] ), 2) + RIGHT("0" + (DT_STR, 4, 1252) DATEPART( "ss", @.[System::StartTime] ), 2) + ".log"

Which gives a package logfilename of MyPackageName20060111142153.log

i.e. Something that contains the package name, and the added benefit that you get a new file for each execution

-Jamie

Overriding any mdx statement using product line 'A' to also include product line 'B'

Using adventure works as a model,
if product line Accessory is used, can something be put in place so that product line Components is also included in its 'Scope'? I started to look at the Scope keyword, but I'm at a loss for understanding it just yet.

The other requirement is also to only have this override be used for transactions on or after 1/9/2007. Is this a possibility as well?

Q:Using adventure works as a model,
if product line Accessory is used, can something be put in place so that product line Components is also included in its 'Scope'?

A:

You can put set in Scope:

Scope ({[Product].[Product Line].[Accessory], [Product].[Product Line].[Components]});
This = 100;
END SCOPE;

Q: The other requirement is also to only have this override be used for transactions on or after 1/9/2007. Is this a possibility as well?

Mosha fixed me here. I thought it is hard to do, but he showed in the following post.

Vidas Matelis

|||

Well, you can always do the following:

Accessory = Accessory + Components;

But this will give you double counting of Components at the All level. To make this apply after 1/9/2007 - you can do:

SCOPE [1/9/2007] : NULL;

Accessory = Accessory + Components;

END SCOPE;

|||

Using the unique name for all of those items and then adding the scope script works, thanks.

Is there anyway to tackle the 'all' value being incorrect because of the duplication?
I tried to add another scope, but it didn't help - probably because all is always the aggregate of its children:

SCOPE [1/9/2007] : NULL;

SCOPE Accessory;

Accessory = Accessory + Components;

END SCOPE;

END SCOPE

|||

One way to deal with 'All' would be to do

FREEZE [All Products];

Before writing assignments on levels below All in Products dimension. This, of course, assumes that there are no other changes which may affect All further in the script.

|||Sweet, thanks!|||Searching through the forums, I have found that I have a use for this as well. The only exception is I need the calculation to work for certain calculated members and not all measures and calculated members. I tried adding another SCOPE statement with my specific measures, but it didn't work as I expected.
Here's an example of the code I have that works for all measures. It would be appreciated if I could get this updated to work for 3 specific measures. thanks

FREEZE [All Products];

SCOPE [1/9/2007] : NULL;

SCOPE Accessory;

Accessory = Accessory + Components;

END SCOPE;

END SCOPE

|||

FREEZE [All Products];

SCOPE ({Measure1, Measure2, Measure3}, [1/9/2007] : NULL);

Accessory = Accessory + Components;

END SCOPE

|||Works perfect. I realized I was trying to use calculated members instead of the measures in which they were derived.

Thanks for the help.