cancel
Showing results for 
Search instead for 
Did you mean: 

Two records with same key (Infocube)

Former Member
0 Kudos

Hi,

I was trying to do, in a update rule, an "IF" condition with two key figures.

IF Kf1 > Kf2. result = Kf1 else result = Kf2.

But the data in the source (datamart Infocube to infocube) have tow records with the same characteristics combination (the same keys)and different amount in the keyfigures, then the result of my "if" condition is not the expected because I understood in the infocube only exists one characteristics combination. :S

I was seeing those records in the manage transaction of the infocube.

Some reason for this?

Thanks and regards

Victoria Leó

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Victoria León,

The one reason you would get this way if one of the characteristic is not mapped the same way acoss all the key figures of the update rules. Just check that.

Bye

Dinesh

Former Member
0 Kudos

Victoria,

Check it out once gain. Is there any ODS in between?

As bhanu said earlier, these 2 records belongs other requests. may be any key is differing in the fact table. check all the primary key's.

All the best.

Regards,

Nagesh Ganisetti.

Former Member
0 Kudos

Hi,

The only one difference is the load, is divided in two data packages. And just in each data package is the amount that is showed in each record ( the records with the same keys).

What I see is the data package have a value in the F table or in some ID, what I can´t see, because in the fields 0CHNGID, 0RECORDTP AND 0REQUID, have the same value for the two records. (0CHNGID = ' ', SID = 0, 0RECORDTP= ' ', sid = 0, and 0RWQUID = REQU_2ZC6ESR3HQ38N7LH0IYNVF809 SID = 24.434).

sO, with this information the option of make an "if" condition have no sense.

Somebody has another option?

Thanks and the best regards,

Victoria

Former Member
0 Kudos

This can happen with parallel loads. Two rows with same set of Char values but in different packets of the same Request, being loaded at the same time.

It really shouldn't be an issue - your update rule will make the KF change as desired. Your queries aggregate KFs based characteristic values, not Dim IDs, so you'll get the totals you expect.

Here's some more info:

There is an RSRV Test that lets you check a dimension for a cube to see if multiple DIM IDs exist for the same combination of Chars - <b>Multiple Entries in Dimensions of a (Basis) InfoCube</b>

Output looks like:

12:02:24 o'clock on 08/25/2006: Start test run for user PIZZAMAN:)

Dimension ZFM_C521: DIMID 61,215 and 61,214 have same characteristic values

Dimension ZFM_C521: DIMID 61,880 and 61,879 have same characteristic values

Dimension ZFM_C521: DIMID 61,366 and 61,365 have same characteristic values

Dimension ZFM_C521: DIMID 61,368 and 61,367 have same characteristic values

12:02:24 on 08/25/2006: Test run for user PIZZAMAN:) completed

You can run the Correct Error option to have it update fact rows to use one of the DimIDs if you want, but unless you have lots of them, I even wouldn't bother.

Here's the description of the test:

<u>Description</u>

This elementary test recognizes whether there are several lines that have different DIMIDs(dimension table key), but have the same SIDs for the selected dimension table for the InfoCube specified. (This can occur by using parallel loading jobs). This has nothing to do with an inconsistency. However, unnecessary storage space is occupied in the database.

<u>Repairs</u>

Since the different DIMIDs with the same SIDs are normally used in the fact tables, they cannot simply be deleted. Therefore, all of the different DIMIDS in the fact tables are replaced by one DIMID that is randomly selected from the equivalent ones. Before a change can be made to the database, the consent of the user is requested.

DIMIDs that have become unnecessary are deleted in the connection. In doing so, not only are the DIMDs deleted that were released in the first part of the repair, but so are all of those that are no longer used in the fact tables (including aggregates). The consent of the user is again requested before this change is made.

former_member188975
Active Contributor
0 Kudos

Hi Victoria,

Could be possible that the 2 'similar' records belong to different requests...

Former Member
0 Kudos

No Bhanu.

The records are from the same infocube, and the same request. :S

Former Member
0 Kudos

You are not checking the complete key (all characteristics, including unit/time) to match the records, or,

these are in different requests (to check this, get all DIMIDs of the two record, and then check the E and F tables).

Former Member
0 Kudos

As ajay said, you are missing the some fields. check once again. it's not possible.

Former Member
0 Kudos

Hi,

I was looking for the DIM id of my record. In the SE11 transaction, with the F table of my infocube, with the dim id, I found two record with exactly the same key.. The table shows like key (KEY_ZCUBEP KEY_ZCUBET, KEY_ZCUBEU, KEY_ZCUBE1, KEY_ZCUBE2, ETC.) the same values for two records.

My DB is oracle, I understand that is not possible. the F table has some fields ocults? time, date of modification, some intern field?

Thanks

Victoria