Showing posts with label fact. Show all posts
Showing posts with label fact. Show all posts

Sunday, March 25, 2012

Copy Date Dimension

Hello Guys and Galls,

I have a fact table with two different keys referring to the same date dimension table. In a query you would use table aliassing to join the date dimension twice.

In AS I created a DSV with two aliasses of the date dimension table. Lets give um names:
- dim_ActivityDate
- dim_OrderDate

Now, I have created a dimension "Activity Date", based on the dim_ActivityDate dimension. I want to create a second dimension, "Order Date", which is a copy of the "Activity Date" dimension, but based on the dim_OrderDate alias from the DSV.

Is there an easy way to do this, or do I have to create the whole dimension using the wizard again?

Regards, Jeroen

Hi Jeroen,

No, you don't need to create two separate physical dimensions. You just need to create one dimension and add it to the cube more than once - a 'role playing dimension'. In Visual Studio just double click on your cube to edit it and assuming you have the dimension already added to the cube once, you just need to right-click on Dimensions box in the bottom-right-hand corner of the 'Cube Structure' tab and select 'Add Cube Dimension'. Add the date dimension again and you'll find that it gets added with a new name, which you can change to Order Date, and then if you go to the Dimension Usage tab you'll find you can join it to your measure group on the dim_OrderDate key column.

HTH,

Chris

|||Splendid! Thnx Chris.

Thursday, March 22, 2012

Copy Database wizard issue

Despite the fact that both the package and the model db have the file locations set to e:\data\nnn, the SSIS package is creating / copying the files into C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data.

This is running as a job - could it be a security issue? I don't see any warning / error messages that would indicate an issue.Update...

This is sounding more and more like a bug.

I changed the model db file locations to the c:\ drive (diff location but known access).

no change

I changed the destination file location in the wizard-created SSIS package to the c:\ drive.

no change

No matter what I do, the wizard insists on putting the files into the program files directory listed above.

Both DB's live on the same physical server but different instances. I've combed through the log file and see no errors or warnings of any sort. The account the package is using (again according to the log) is an admin-level account.

I don't see anything on the feedback / bug site related to this.|||Given the deafening silence on this post, I've submitted a bug report. Feedback # is 236131|||

You were right to submit this as a defect. For others reading this thread, the link to the bug is: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=236131

We will investigate the issue and get back to you through the Connect site.

Regards,

Copy Database wizard issue

Despite the fact that both the package and the model db have the file locations set to e:\data\nnn, the SSIS package is creating / copying the files into C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data.

This is running as a job - could it be a security issue? I don't see any warning / error messages that would indicate an issue.Update...

This is sounding more and more like a bug.

I changed the model db file locations to the c:\ drive (diff location but known access).

no change

I changed the destination file location in the wizard-created SSIS package to the c:\ drive.

no change

No matter what I do, the wizard insists on putting the files into the program files directory listed above.

Both DB's live on the same physical server but different instances. I've combed through the log file and see no errors or warnings of any sort. The account the package is using (again according to the log) is an admin-level account.

I don't see anything on the feedback / bug site related to this.|||Given the deafening silence on this post, I've submitted a bug report. Feedback # is 236131|||

You were right to submit this as a defect. For others reading this thread, the link to the bug is: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=236131

We will investigate the issue and get back to you through the Connect site.

Regards,