Way to handle fact table

hi,
let;s say that we have a fact table with 250 millions rows of data.
9 dimensions.
My question is ,even we make aggregates to all possible levels,the queries in low levels are really slow(30-60 seconds).
We use indexes in the fact table in columns where we have the joins to dimensions.
Any ideas???
Is it a way to have the same logical fact and make more datasources,meaning
measures in fact
and let;s say 2 dimensions,product and supplier.
In one product_dim have the measures of the items begins from a to g ,
second product_dim have the measures of the items begins from g to t ,
and third product_dim have the measures of the items begins from u to z .
So if the queries wants data from one Dsource go from a smaller fact (with the appropriates aggregates)...
and if the query requires data from both or all of them,Bi suite make the union all by itself...
Any other recomondation...
tnks

I'd start with a trainining education session with your users discussing the merits of star schemas.
Accept OBIEE does not handle Outerjoins that well in current guise (at least with extending the outer join syntax to where clause predicates / filters)
Resolve any missing fact / dimension records with a '-1' dimension key in the fact and a corresponding -1 PK with 'unknown' attributes in the dimension - not everybody likes this idea but it is a tradeoff with the outer join problem.
Change your ETL routines to create either
a) consolidated facts where the join is already done (ie between sales orders + orders + invoices)
b) simple indexed bridge / mapping tables that again, hold 'unknown' for missing relationships between sales orders / invoices / and negate the need for outerjoins.
Just my 2c - a common misconception is that OBIEE 'can do everything' - Its only going to be as good / fast as your underlying database design - im sure you already know this but i've met a few power users / developers who feel they dont need to change the ETL at all - both OBIEE and ETL should compliment each other as a solution

Similar Messages

How to handle Fact tables with different granularity in OBIEE 11g RPD

Hello Everyone,
I have got stuck here and need your help.
I have two fact tables (Say F1 and F2... F1 is containing data at month-level and F2 is containing data at day level) and one Date DIMENSION TABLE. Date_Code is the PK of Date dimension table.I need to use time-series functions also.
Can anyone tell me how to model this requirement in the RPD.
Can we use a single dimension table(Here Date dimension table) with two fact table of different grainularity? What would be the best way to implement this requirement?
Thanks in advance :)

Hi Veeravalli,
Thanks for your reply :)
Let me explain the problem in more detail. I have one Date dimension(Date_Code,Month_Code,Quarter_Code,Half_Year_Code,Year_Code). Here Date_Code is the PK.
In F1---->Date (Using Month_Code key)
F2-------->Date (Using Date_Code Key)
Level based hierarchy is there starting from Year to Date.Each level has PK defined and chronological key selected.
F1 has level set to Month and F2 has level set to Day.
Now if i am using ago() function on measure of F2 (having day level data) then it's working fine but if i am using ago() function on measure of F1...I am getting an error at Presentation service: Date_code must be projected for time-series functions.
So the whole issue is with time-series functions. As per my research...I think for time series the tables in the physical model containing the time dimension cannot join to other data sources, except at the most detailed level but here i am joining with F1(using Month_Code which is not the most detailed level).
So kindly let me know how to achieve this in rpd?

Best way to combine multiple fact tables in single mart

Hi, quick question that I think I know the answer to, just wanted to bounce it off everyone here to make sure I'm on the right track.
I have a HR datamart that contains several different fact tables. Some of the facts are additive across time (i.e. compensation - people get paid on different days, when I look at a month I want to see the total of all pay dates within that month). The other type of fact is more "status over a set of time" - i.e. a record saying that I'm employed in job X with a salary of Y from a given start date to a given end date.
For the "status over time" type facts, if I choose January 2009 (month level) in the time dimension, what I'd really like to see is the fact records that were in place "as of" the last day of the month - i.e. all records where the start date is on or before 1/1/2009, and whose end date is on or after 1/1/2009. Note that my time dimension does go down to the day level (so you could look at a person "as of" the middle of the month, etc. if you're browsing on a day-by-day basis)
I've set up the join between the time dimension and the fact table as a complex join in the physical layer, with a clause like "DIM_DATE.DATE >= FACT.START_DATE AND DIM_DATE.DATE <= FACT.END_DATE". This seems to work perfectly at the day level - I have no problems at all finding the proper records for a person as of any given day.
However, I'm not quite sure how to proceed at the month level. My initial thought is:
a) create a new LTS for the fact table at the month level
b) in the new LTS, add the join to the time dimension
c) in the new LTS, add a where clause similar to LAST_DAY_IND = 'Y' (true for the last day of each month).
Is this the proper way to do this?
Thanks in advance!
Scott

Hi Scott,
I think you're on the right track but I don't think you need the last part. Let me generalize the situation to the following tables
DAILY_FACT (
DAILY_FACT_KEY NUMBER, -- PRIMARY KEY
START_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR START DATE
END_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION FOR END DATE
DAILY_VALUE NUMBER); -- FACT MEASURE
MONTHLY_FACT(
MONTHLY_FACT_KEY NUMBER, -- PRIMARY KEY
MONTH_DATE_KEY NUMBER, -- FOREIGN KEY TO DATE DIMENSION, POPULATED WITH THE KEY TO THE LAST DAY OF THE MONTH
MONTHLY_VALUE NUMBER); -- FACT MEASURE at MONTH LEVEL. DATE_KEY is at END of MONTH
DIM_DATE(
DATE_KEY NUMBER,
DATE_VALUE DATE,
DATE_MONTH VARCHAR2(20),
DATE_YEAR NUMBER(4));
DIM_DATE_END (ALIAS OF DIM_DATE for END_DATE_KEY join)
Step 1)
Make the following three joins in the physical layer:
a. DAILY_FACT.START_DATE_KEY = DIM_DATE.DATE_KEY
b. DAILY_FACT.END_DATE_KEY = DIM_DATE_END.DATE_KEY
C. MONTHLY_FACT.DATE_KEY = DIM_DATE.DATE_KEY
Note: The MONTHLY_FACT DATE_KEY is joined to the same instance of the date dimension as the START_DATE_KEY of the DAILY_FACT table. This is because these are the dates you want to make sure are in the same month.
Step 2)
Create a business model and drag DIM_DATE, DAILY_FACT and DIM_DATE_END into it.
Step 3)
Drag the physical table MONTHLY_FACT into the logical table source of the logical table DAILY_FACT.
Step 4)
Set DAILY_VALUE and MONTHLY_VALUE to be aggregates with a "SUM" aggregation function
Step 5)
Drag all required reporting columns to the Presentation layer.
Step 6)
Create your report using the two different measures from the different fact tables.
Step 7)
Filter the report by the Month that joined to the Start Date/Monthly Date (not the one that joined to the end date).
Step 8)
You're done.
The act of combining the two facts into one logical table allows you to report on them at the same time. The strategy of joining the START_DATE_KEY and the MONTH_DATE_KEY allows you to make sure that the daily measure start date will be in the same month as the monthly fact table.
Hope that helps!
-Joe
Edited by: Joe Bertram on Jan 5, 2010 6:29 PM

How to handle 3 different fact tables and measures within a DAX query?

I am writing a DAX query in DAX studio in Excel against a tabular model that has 4 different Fact tables, but they share the same dimensions. (There's some long story I can't get into here, but unfortunately this is the structure) I want to
include measures from the 4 fact tables, summarize by the dimensions in a single query output that can be used for a pivot table. So far I have something like this:
EVALUATE
FILTER
    SUMMARIZE
        FactTable1,
        DimensionTable1[Value],        DimensionTable2[Value],
        DimensionTable3[Value],
        Dimensiontable4[Value],
        'dimDateTime'[Month PST],
        DimDateTIme[FiscalYear PST],
        "Measure Score",
        FactTable1[Measure 1],
        "Measure Score 2",
        FactTable1[Measure 2],
    ,Company[CompanyName]="Company ABC"
What I want to do is summarize the 3 fact tables by the same dimensions, but I am not sure how to do that within a DAX query. I am getting an error if I try to include another table statement in the original SUMMARIZE function, even though the FACTS
do share the same dimension. Is there an easy way to do this?

You can use ADDCOLUMNS to add the data from other tables, but you need to use within the SUMMARIZE the fact table that determines the cardinality of the output. If you are not sure (e.g. you project cost and revenues from two fact tables by month and there
could me months with cost and no revenues, but also months with revenues and no costs), then you should use CROSSJOIN and then FILTER.
You query might be written as (please note CALCULATETABLE instead of FILTER to improve performance):
EVALUATE
CALCULATETABLE (
    ADDCOLUMNS (
        SUMMARIZE (
            FactTable1,
            DimensionTable1[Value],
            DimensionTable2[Value],
            DimensionTable3[Value],
            Dimensiontable4[Value],
            'dimDateTime'[Month PST],
            DimDateTIme[FiscalYear PST]
        "Measure Score", FactTable1[Measure 1],
        "Measure Score 2", FactTable1[Measure 2]
    Company[CompanyName] = "Company ABC"
Marco Russo http://www.sqlbi.com http://www.powerpivotworkshop.com http://sqlblog.com/blogs/marco_russo

How do you handle update and delete rules for fact tables?

I have a fact table with a composite key of 5 columns. Two of the columns are FKs to the date dimension. I was setting the delete/update rules for the FK relationship in SSMS and it had a problem with me creating cascade action on the FKs that connected
to the date dimension.
What is the proper way to set up FK relationships in fact tables with SSMS when you have composite keys as most fact tables do?

Yeah I understand all that. What I'm trying to do is to protect my database from RI violations that occur by production support people blowing away stuff in a dimension table but forgetting to blow away related records in the fact table. I want those fact
records deleted automatically so we don't have orphan records which was a real issue at a previous engagement. Production support is usually just people that know SQL and some relational modeling. It's not too likely they will understand the details of dimensional
modeling enough such that they would know that they had to blow away the fact record first.
My problem is I have a FK to a role playing dimension (the date dimension in this case). So basically I have to columns in the fact table that have a FK relationship to the PK of the date dimension. When I create both relationships SSMS and try to have both
of them cascade delete SSMS has an issue with it.
The error I get is:
Unable to create relationship '[relationship name]'
Introducing Foreign Key constraint '[constraint name]' on table '[table name]' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other foreign key constraints.
I can go ahead and put no action and the table will save fine. The question now becomes how does the cascade delete actually work. Can I just set one part of the key to cascade delete?
Actually I just realized that this is an even bigger design issue. What DOES happen to a fact record when one of it's dimensions gets deleted and I've got full RI set up on the table?
Or am I totally thinking about this wrong. Do you set up cascade deletes in a dimensional model? Is there a way to prevent deletes from the dimension table if there are related fact records?

What's the best way to handle the growth of the mdm.tblTransaction table?

Can anyone suggest a good way to handle the growth of the mdm.tblTransaction table? This table logs all the MDS transactions and the history of the data residing in it is required for auditing purposes. Hence we can't delete this data. I'm looking for options
on how we can maitain this table ongoing. It is going to perform badly eventually. We currently have 15 Million transactions in this table.
What options can we look at?

In the vnext sql server, MDS will support cleaning based on log retention policy.
In the sql2014/sql2012, you have to clean up the table manually.
An sample sproc that can be reused is attached below.
==============================================================================
Copyright (c) Microsoft Corporation. All Rights Reserved.
==============================================================================
SELECT * FROM mdm.tbl_7_TR where LastChgDTM < '2014-10-22';
EXEC mdm.udpLogCLeanup 7, '2014-10-22';
SELECT * FROM mdm.tbl_7_TR where LastChgDTM < '2014-10-22';
CREATE PROCEDURE mdm.udpTransactionsCleanup
@Model_ID INT,
@CleanupOlderThanDate DATE
WITH EXECUTE AS N'mds_schema_user' -- Execute as a user that has permission to select on [tblUserGroupAssignment], [tblBRBusinessRule], [udfSecurityUserBusinessRuleList]
AS BEGIN
SET NOCOUNT ON
DECLARE
@SQL NVARCHAR(MAX)
--Annotation table names
,@TransactionTableName sysname
,@AnnotationTableName sysname;
SET @TransactionTableName = 'tblTransaction';
SET @AnnotationTableName = 'tblTransactionAnnotation';
BEGIN TRY
--Delete all Annotations on transactions being deleted issues
SET @SQL = N'
DELETE [mdm].' + QUOTENAME(@AnnotationTableName) + N'
FROM [mdm].' + QUOTENAME(@AnnotationTableName) + N' as tannt
JOIN [mdm].'+ QUOTENAME(@TransactionTableName) + N' as txn ON tannt.Transaction_ID = txn.ID
JOIN [mdm].[tblModelVersion] as tmv ON txn.Version_ID = tmv.ID
WHERE tmv.Model_ID= @Model_ID AND txn.LastChgDTM <= @CleanupOlderThanDate
EXEC sp_executesql @SQL, N'@Model_ID INT, @CleanupOlderThanDate DATE', @Model_ID, @CleanupOlderThanDate;
--Delete all transactions older than the specified date
SET @SQL = N'
DELETE [mdm].' + QUOTENAME(@TransactionTableName) + N'
FROM [mdm].' + QUOTENAME(@TransactionTableName) + N' txn
JOIN [mdm].[tblModelVersion] tmv ON (txn.Version_ID = tmv.ID)
WHERE tmv.Model_ID = @Model_ID AND txn.LastChgDTM <= @CleanupOlderThanDate
EXEC sp_executesql @SQL, N'@Model_ID INT, @CleanupOlderThanDate DATE', @Model_ID, @CleanupOlderThanDate;
RETURN(0);
END TRY
--Compensate as necessary
BEGIN CATCH
-- Get error info
DECLARE
@ErrorMessage NVARCHAR(4000),
@ErrorSeverity INT,
@ErrorState INT;
EXEC mdm.udpGetErrorInfo
@ErrorMessage = @ErrorMessage OUTPUT,
@ErrorSeverity = @ErrorSeverity OUTPUT,
@ErrorState = @ErrorState OUTPUT;
RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState);
--On error, return NULL results
--SELECT @Return_ID = NULL;
RETURN(1);
END CATCH;
SET NOCOUNT OFF
END --proc
GO

What is correct way to join a start/end date driven dimension to a fact table in data foundation?

I have a bad universe or a data design issue.
Several versions of hierarchies reporting store entities in reporting Fact measures.
Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                            START_DATE
                                                                            END_DATE
                                                                            STORE_NUMBER
                                                                            ORG_HIERARCHY
                                                                            CURR_FLG   (Y/N)
Fact table :                                                         ORG_KEY
                                                                             CALENDAR_KEY
                                                                             TRANS_DATE
                                                                             $amount
Calendar Dimension:                                            CALENDAR_KEY
                                                                              DAY_DATE
                                                                               FY_WEEK          (201452)
                                                                                FY_PERIOD      (201412)
                                                                                FY_QUARTER   (201401)
                                                                                 FISCAL_YEAR    (2014)
Users WISH:
Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
Daily (Would be Calendar.Day_Date in Filter) ,
Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK as entered,
Month to date,
Year to date,
AdHoc queries.
My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail. I have not gotten @Prompts to work in joins, derived tables, etc. in the data foundation. Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked.
Please help!   ANY ideas would be appreciated.   .

{Note that abbrevations in brackets are just for short form further down the answer}
Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
Create an alias of Calendar Dim and call it Transaction Date (TD)
Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
The above predefined condition when added to your data query will return only yesterday's transactions.
However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
If you have any more questions about how this approach would work please shout.
As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

Best way to connect two fact tables when no conformed dimension exists

Can anyone please elaborate how would I connect two fact table without any conformed dimension. Let say FACTA, FACTB. FACTB is related to a dimension "StatusDim". I want to select the count of all FACTA item which are related to FACTB items with
a particular status. I have found the following article but just wondering whether it is the best practise to connect two fact tables directly.
http://bifuture.blogspot.com/2011/11/ssas-selecting-facts-with-reference.html
Thank you

Hi Ahsan,
After read the blog you posted, I think it's a pretty good solution to create a view in the relational database or a named query in the Data Source View containing as the the columns in FACTA and FACTB. Then build a dimension from it, setting the "Null processing"
property (you have to click the "plus" two times for the "Key Columns" property of the attribute in BIDS to access this property) to "UnknownMember". And then use this dimension for the many-to-many relationship. Dimensions from FactA can benefit of the reference
relationship between FactA and FactB and therefore a powerful solution it is.
Regards,
Charlie Liao
If you have any feedback on our support, please click
here.
Charlie Liao
TechNet Community Support

One DIMENSION, Two FACT Tables - One WEEKLY grain, one DAILY grain

All the OBIEE gurus, thanks for checking out this post.
Background: We have a common DIMENSION referencing two FACT tables having different granularity.
DIM = Customer Dim
FACT = Forecasting (Weekly granularity)
FACT = Sales (Daily granularity)
There is a need to report from the Customer Dimension table AND access the Forecasting FACT (weekly grain) & Sales FACT (daily grain).
Example of query is listed below:
Give me customer = 'ABC' and the forecast and sales for a specific time period.
What will be the best way to handle something like this? I have seen examples of handing multi-fact table access in OBIEE but the granularity of both the FACT tables is different (weekly vs. daily).
Any help with an example is greatly appreciated.
Thanks,
Sunshine

Hi.
This one:
Joining different level aggregation measures together into a single logical fact table
http://108obiee.blogspot.com/2009/07/joining-different-level-aggregation.html
Regards
Goran
http://108obiee.blogspot.com

A loop between two or more fact table

Hi,
How Does Discovere solve the loop between tables ? (join between with more fact table in a star schema)
Microstartegy resolve this problem with diffrent select and union the results. Instead BO use the contexts.
Thank you.
null

I don't think Lightroom handles cmyk images.
For rgb and gray, you can stack the images, or make the gray from a virtual copy of the rgb. In this way, simply unstacking the images results in your requested "show corresponding images".

Protect fact table in BI with S_TABU_DIS

Hello all,
I want to restrict access for particular DSO/Cube tables (fact table) via RSA1, LISTCUBE, SE16 or SM30, searched for a solution and found this thread: <u>Using Wildcard characters in tables in S_TABU_DIS</u> but it did not solve my problem.
As far as I am informed cube tables are generated automatically when a cube definition is transported from development to production system (as written in the above mentionned thread: they get generated on the fly). Though it is possible to assign a specific authorization group to these tables and to create roles with restricted access for object S_TABU_DIS these authorization groups have to be assigned to these tables on each system (that means development on production!).
What happens if a cube must be changed and transported again?
I guess these manual tasks are gone then and one has to redo the assignment to the authorization groups.
Are there any other things that might be affected of this handling?
Thanks in advance for your inputs,
Petra

Petra,
Did you find a way to address this issue? We are trying to figure out how to secure table access without having to add table auth groups to hundreds of tables.
Regards,
Janice

Content Tab: None of the fact tables are compatible with the query request

Hi All,
**One thing I am not clear yet of all my years with OBIEE is working with the content tab in BMM.**
I have made a rpd the joins in physical layer as shown below:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056545119428530
And the BMM layer as:
https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056519553812930
Error I am getting when i run a request from the 3 columns from the selected 3 tables is:
Dim - Comment Code Details
Fact - Complaint
Dim - Service Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14020] None of the fact tables are compatible with the query request Sr Num:[DAggr(Fact - Complaint.Sr Num by [ Dim - Service Details.Sr Cat Type Cd, Dim - Comment Code Details.Cmtcode name] )]. (HY000).
I get no error for consistency.. I read everywhere and I know i need to set the appropriate aggregation levels in the various dims and facts LTS properties to help OBIEE understanding our model, but how to do that.. how do i decide... how should I approach, what should be the aggregation level, what details.
When i click More button i see different options: Copy, Copy From, Get Levels, Check Level, what do these mean.
Aggregation Content, group by - Logical Level or Column which one should i choose and how should I decide.
Can anyone explain the Content Tab in details and from scratch with some example and why we get these errors.... I know many people who are well versed with many other things related to RPD but this. A little efforts of explaining from you guys will really be appreciated.
Thanks in advance,
Dev

Hi Deepak,
Option 1:
My tables in physical layer are joined as below:
D1--> F1 <--D2--> F2 <--D3
Same way i model it in BMM
D1--> F1 <-- D2--> F2 <--D3
Here D1 is non Conformed Dimension for F2 and D3 is non Conformed dim for F1. Later create Dimensional hierarchies, I tried setting up the content levels
I go Sources>content tab of Fact F1 I set
Dimensions----------- Logical level
D1---------------------- D1 Detail
D2---------------------- D2 Detail
D3---------------------- D3 Total
then, I go Sources>content tab of Fact F2 I set
Dimensions----------- Logical level
D1---------------------- D1 Total
D2---------------------- D2 Detail
D3---------------------- D3 Detail
Then, I also go in all the dimensions and set their content levels to Details, but it still gives me errors not sure where I am going wrong in setting the content levels.
I need to know whether the way I have modeled it in BMM is right,
Option 2:
I can combine the two facts in a single Logical Fact or the above design should also work.
(F1&F2)<--D1, D2 , D3 joined separately using complex logical joins.
what will be the content tab details?
Thanks,
Dev

NQS ERROR:14025 NO FACT TABLE EXISTS -after migrating from 10g to 11g

NQS ERROR:14025 NO FACT TABLE EXISTS AT THE REQUESTED LEVEL OF DETAIL in all the reports after migrating from 10g to 11g ...
then we applied the patch (One-off Patch for Bug: 11850704) for the error <<NQS ERROR:14025 NO FACT TABLE EXISTS AT THE REQUESTED LEVEL OF DETAIL>>
But after applying the above the above patch we are still getting the same error.
but in the above patch instructions file - Post deployment instructions to create the Variable
Post Install Instructions:
- To revert to the 10g navigator behavior for handling conforming dimensions,
you must set the following session variable via an init block in the RPD:
NO_FORCE_TO_DETAIL_BIN=1
The default value for the above variable is 0.
- Restart all servers (Admin Server and all Managed Server(s))
but we didn’t find the process to create the specified variable and Initialization block in the RPD
Can you please suggest us how to go further.
Our questions are:

Hi
Refer the below thread.
obiee 11g non-conforming dimensions and nQSError 14025
Might be help you/
Thanks,
satya

What's the best way to handle this?

I'm not sure what APIs/setup to use for this situation:
A company wants to store data projects they do for clients. Each year, the data fields are set (as a result of gov't requirements) and they won't change for any client project for that year. however, the fields required can (and usually do) change every year. So things they require this year, might not be needed the next year and new fields might be introduced.
While there are likely to be many common fields from year to year, there's no way to guarantee which ones will remain consistent. They also want to be able to do searches on the data and fields, for projects within a year and across years.
What's the best framework/API/configuration to handle this? EJB? Simple JDBC? If so, how should the database be handled? Won't it have to constantly create new fields in a table? Or is there another way to handle this?
What's the best way from a "clean architecture" standpoint?

dang, I really have to start over? I finally got all this stuff working again. well, hopefully it won't be as big a pain this time since the data won't be coming from a different machine. After completing the Migration Assistant process, I had to reinput a bunch of serial numbers for apps, reinstall print and mouse drivers, etc... I've finally got the new machine up and running smoothly and now I gotta start over? Sigh.
I was hoping that either I could rename the current account after deleting the other one, or just move everything from one account to the other and then delete the 'RJM' account.
ok, so it sounds like here are the steps I need to take:
- make another full cloned backup of this current machine in Super Duper
- reboot this machine using the advice in the first post, wipe everything clean and reinstall the OS
- create a new account like 'user1' and re-do software update (which is like 2.5 gig worth of stuff) and takes like an hour even on a high speed connection
- then re-do the migration assistant process to the properly named account
- then delete the 'user1' account
does that sound right?

Issue using one 2 Fact tables with one dimension Table.

Hi,
I have 1 Dimension table X and 2 Fact tables A and B
X is joined to Both A and B for Loan Amount ( with A) and for colleatral amount (with B) when I am selecting the X.Product_Name, A.Loan_Amt, B.Collateral Amount, it is giving an error message
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table EIP Collateral FACT) does not contain mapping for [EIP Reporting FACT.PD ID]. (HY000)
Any clues???
Is there a Inner or Outer join which needs to be created or set in the RPD to get the desired results???

Ok..
I have one table which is Porfolio Details which has Portfolio name, Product Category , Product Name, Product ID, Product sources code.- This is my Dimension table.
I have another 2 set of fact tables : EIP Reporting FACT and EIP Collateral FACT..
These two tables are joined to Portfolio Details table.
EIP Reprting FACT gives portfolio wise Loan Amount
and EIP Collateral FACT gives Portfolio wise Collateral Amount details for same set of customer..
Now, I am selecting Portfolio Name, Product Category, Product Name,SUM( EIP Reporting FACT.LOAN_AMOUNT), SUM(EIP Collaetral FACT.Collateral_Amt) in a report
Now, on selecting these columns I am getting that error message which is related to mapping.
If I take any column from Portfolio details table and any column from EIP Reporting FACT- It works.
If I take any column from Portfolio details table and any column from EIP Colletral FACT- It works.
But if I take any column from portfolio table and columns from both FACT tables it gives mapping error...
Hope I am able to explain the issue in a better way now..
Edited by: help-required on Mar 11, 2010 6:53 PM
Edited by: help-required on Mar 11, 2010 6:53 PM

Way to handle fact table

Similar Messages

Maybe you are looking for