DTP: Record filtered in advance as error records with the same key exist

[former_member185837]

Hi,

I have a transformation from one DSO to the same DSO. The aim is to update all data records in the DSO with the information provided by other InfoProviders/characteristics. The data are updated in the DSO through a Data Transfer Process (DTP) in full mode. Such a DTP extracts data from the Active Table (with Archive) of the DSO.

When I run the DTP, many error messages RSM2 722 (Record filtered in advance as error records with the same key exist) are sent to the monitor, and so the loading is unsuccessful.

I can't figure out why this happens. How is it that duplicate records are extracted from the active table (not the change log!) of a DSO?

Thanks & Regards,

Davide

[Pravender · Accepted solution]

Create an error DTP, so all the error records will be collected in error stack which you can correct and load.

If error DTP is already available then delete existing records from error stack. Also delete the PSA.

If the DSO you are using is a write optimized DSO then set the checkbox "Do not check uniqueness" to ON.

[former_member185837 · Accepted solution]

Hi Pravender,

yes, it's right: if you have an error DTP the records that give the problem are filtered out and put in the error stack--provided the error DTP can deal with a fairly big number of error records!

However, I can't understand why the system considers such records as duplicates in the first place. After all, I'm extracting data from the active table of a DSO, thus no duplicate records should be extracted at all: records are guaranteed to be unique in a DSO's active table, aren't they!

Since I do not expect any duplicate records, I have no idea as to how to correct those records! Moreover, the number of error records collected is unbelievably high, so it'd be unfeasable to correct them all!

Finally, please notice that I don't have any PSA, as I'm extracting from a DSO (a standard DSO, not a write-optimised one) and loading the very same DSO, through a DTP (i.e. no InfoPackage is involved).

Cheers,

Davide

[Former Member · Accepted solution]

Hi Davide,

Could you please check the semantic group defined in the DTP.

If the semantic group is not same as the key of the DSO then in that case it can happen that error in one record can collect others in error stack.

For example:-

If the key of the DSO is ordernumber and orderitem.

but the semantic group is ordernumber only then error in ordernumber 1001 and item 10 would collect all records with ordernumber 1001 and item = <any> in error stack.

Hope it helps you

Manish Sharma

[former_member185837 · Accepted solution]

Thank you for your suggestion, Manish.

I've checked it out and, in fact, the semantic group is the same as the key of my DSO.

Besides, the error occurs in the filtering step of the DTP, not in the transformation step. This means the error does not depend on some check in the transformation, but on the very records that gets extracted: the system believes that some records are duplicate, when in fact aren't (at least, shouldn't!)

Thanks again,

Davide

[former_member185837 · Accepted solution]

Hi,

I've done some further analysis and it seems the problem depends on the error stack of the DTP I'm using.

Although no data is showed when I push the error stack button, from the DTP monitor, in fact there are fairly many records in the dictionary table for the DTP's error stack (table /BIC/B0000402000, in my case). I think these are the records which are found to be duplicate to those extracted from the DSO's active table.

I'll give you an update later on.

Thanks, Davide

[former_member185837 · Accepted solution]

Hello,

now my question is: from the Data Warehouse Workbench, how can I visulise all the records in a DTP's error stack--i.e. related to all the requests? Because it's tediuos to go to the monitor for every request and check whether there are records for that request in the corresponding error stack!

I'm using transaction SE16 to get such information, but is a more direct and intuitive way from the Workbench?

Thanks, Davide

[Former Member]

This message was moderated.

[Former Member]

Go to transaction RSRV and do all the elementary tests and combinations tests for your source DSO and Cube. If any SID problem or any other, you can correct ther error ( button in the header)

[former_member185837]

Hi N.Ganesh,

I did all the elementary tests for ODS objects for my source DSO and no issue was reported.

My target InfoProvider is the very same DSO, so I think I don't need to perform tests for any InfoCube.

Thanks, Davide