change not effective in production?

[Former Member]

Dear Friends,

I had improved the code for a variable exit used in a planning sequence.

Only the exit code was changed to handle data processing better. Thus, no filter or modeler settings were changed.

In development, this change proved to have fixed the problem.

I transported it to QAS and it also solved the problem there.

When I transport to Production, the old error remained. The planning sequence runtime gave the same error.

It is a generate combinations function.

I checked the exit was transported successfully and modeler settings are the same as in Development.

The error said step 'x' was having error.

I do not know how to tell where is this step 'x'. If the system is able to identify a certain step giving problem, how can i know more what this step is exactly?

Its either in the characteristics relationship or in the filter.

How can I tell for sure what is it complaining about that prevents the generate combinations function to run properly?

Hope to get some tips. What steps can I take to narrow down the problem or what else should / could I do?

regards

YHogan

Edited by: Yohannes Hogan on Jun 19, 2008 5:02 PM

[Former Member · Accepted solution]

Hi YHogan,

This error usually means that the data being processed in inconsistent with the characteristic relationship number 'x' (if a char.rel. is defined at number 3, it will say step 3). Do you have different char. rel. settings in D and P systems? Or maybe, in P system, there are some combinations present in the data which are inconsistent with the char. rel.

[Former Member · Accepted solution]

Dear Mayank,

Yes, D and P are having identical characteristic relationship and all other configs.

For my case, 2 characteristics are used as 'Source' and 4 characteristics are specified as 'Target' derived via Attribute Type.

Kindly could you advise how the inconsistency can be determined and how to determine which object is causing the inconsistency.

Thank you in advance. Points awared for your useful reply.

Regards

YHogan

[Former Member · Accepted solution]

Hi,

If both configs are same, then there might be some data in the cube in the P system which could be causing this issue. Was any data loaded in the planning cube through any data source? Or did you switch on the characteristic relationships at a later point of time (maybe some inconsistent data was entered before they were switched on)? You will have to do more analysis to zero in on the cause of the issue.

[Former Member · Accepted solution]

Dear Mayank,

Thanks, points awarded.

Sorry, I do not yet understand what is meant by data being inconsistent. I hope to understand what is inconsistent data . could you be generous and show me a simple example using records?

am i right to say that characteristic combination will 1st check what data already exist in the cube before data is generated and written to the plan cube ?

am I right to say that if there is inconsistent data pre-existing , characteristic combination could fail due to .....?

I thought characteristic combination will generate whatever combination is derived in the target characteristics , generating records that do not yet exist also ?

Could characteristic combinations be generated as new records if one of the target attribute-derived characteristics is derived as 'blank' ?

many thanks!

Yhogan

Edited by: Yohannes Hogan on Jun 25, 2008 6:15 PM

[Former Member · Accepted solution]

Hi,

A very simple example. Lets say Product P1 belongs to Product Group PG1 (Product Grp is an attribute of Product and so this relation is stored in master-data). Now, lets say you have a record stored in the planning cube which has the combination (P1, PG2) - this could have come through a load or at a time when characteristic relationship between prod grp and product was not created/not active. When this existing record gets processed by the char. rel., it will throw an error (if this record remains in the cube but is not read/modified, it would not create a problem).

Regarding your second question, its not a problem if the value for a target characteristic for a char rel is #, but please note that if the value of the source char is #, then derivation does not happen.

As I mentioned before also, you will have to locate the exact error yourself. I just tried to explain to concept.

[Former Member · Accepted solution]

Dear Mayank,

Thanks for that excellent advice.

Full points!

Best regards,

YHogan