Ruled cell not released for write

[kenship]

Hi, I have the following:

1. Cube has rule calculation for only "Active Version"
2. Active Version is attribute in Version dimension
3. Cube subject to Year End Process ("YEpro")
4. YEpro calls for 2 processes: a. "Export" and b. "Import"
5. Export includes rule calculated data
6. Between Export and Import, YEpro updates attribute in Version dimension to next Version

Problem:
Despite the exported file includes calculated data, the Import process could not write the calculated data back to cells of the previous Active Version as if the cells are blocked due to rule. However, the attribute should have already been updated to release the cells for write back.

I did a manual change in the Version dimension to change attribute "Active Version" and I can see the cells in the cube of the previous "Active Version" is released for write back.

My conclusion at this point is: the release won't happen until all processes are completed. If I need to write back completely then I need to separate the write back process from the Year End Process series.

Any advice is appreciated, thanks for reading.

Kenneth

[tomok]

If this "Active Version" you are referring to is an alias then you may need to separate the export and the import processes and update the alias in between the two. I have had similar issues in the past with using an alias in this manner and that is what I had to do.

[kenship]

Thanks for the reply.

Actually the way the attribute working is just a "Y" under the attribute "Active" in the "Version" dimension.

If my situation is the same as yours then can we say that update due to attribute only "really" happens when the process series is completely finished?

Kenneth

If this "Active Version" you are referring to is an alias then you may need to separate the export and the import processes and update the alias in between the two. I have had similar issues in the past with using an alias in this manner and that is what I had to do.

[tomok]

Actually the way the attribute working is just a "Y" under the attribute "Active" in the "Version" dimension.

Well, that's not exactly how it works because just setting some attribute on an element is not going to control whether or not you can write to it without some special code in the rules for that cube that act on that attribute. What I was referring to was the practice of assigning an alias to a version and use the value "Active Version". This way you can hard-code the value "Active Version" in processes and reports and never have to change them as they will then always act on whichever version you have designated as the "Active Version". For your specific instance it would appear that the change in the flag value is not being committed until the main process finishes so your rule is still acting on the old flag value.

[kenship]

Got it.

In my case I'll probably separate the processes and test.

Thanks for your input.

Kenneth

Actually the way the attribute working is just a "Y" under the attribute "Active" in the "Version" dimension.

Well, that's not exactly how it works because just setting some attribute on an element is not going to control whether or not you can write to it without some special code in the rules for that cube that act on that attribute. What I was referring to was the practice of assigning an alias to a version and use the value "Active Version". This way you can hard-code the value "Active Version" in processes and reports and never have to change them as they will then always act on whichever version you have designated as the "Active Version". For your specific instance it would appear that the change in the flag value is not being committed until the main process finishes so your rule is still acting on the old flag value.

[PavoGa]

What I think is happening is that attribute change is uncommitted data within the YEPro transaction and therefore when the Import process runs, the rules are still seeing the Active Flag as "Y" on the previous version. The attribute change is not committed until YEpro completes.

You can test this rather easily by executing CubeSaveData('}ElementAttributes_Version') right after the change to the attribute. Alternatively, have an intermediate process that sets the attribute value. Using ExecuteProcess may do the trick, but also RunProcess followed by SLEEP() would guarantee the commit.

[MarenC]

Hi,

I tried this but in just a single process. So the Version had flag Y against attribute ActiveVer and the cells were rule based.

In the process, I refer to a cube view that references the Active version.

On the Prolog I update the attribute to make ActiveVer = n and then on the data tab I cellput the values to the measure that had a rule which references the ActiveVer attribute.

At first it didn't work because I was referring to the active version (via some mdx) in the view that is the datasource for the process. As soon as I hard coded the version in the view and removed the mdx the process ran and updated the previously rule based cells.

Not sure if that gives any insight or not!

Maren

[PavoGa]

To correct my earlier statement, because it may be partially incorrect: the update to the version is not committed for the Import process because the attribute update and Import are all within the Prolog procedure. You may be able to resolve your problem by simply moving the import to the Epilog. One, if not all, of the these suggestions should work.

[kenship]

I tried implementing the suggested solution.

Just moving the load process to Epilog won't work.

CubeSaveData must be added after attribute update.

Thanks to all.

Kenneth

[EvgenyT]

Try updating attribute with RunProcess, so it commits entirely outside of the processing chain.

CubeSaveData must be added after attribute update.

- No, it only matters if you want to serialize changes to the disk. It does not come into equation when you are committing data.

[kenship]

Probably. But for simplicity I'd rather not create another process to do the job.

Thanks!

Try updating attribute with RunProcess, so it commits entirely outside of the processing chain.

CubeSaveData must be added after attribute update.

- No, it only matters if you want to serialize changes to the disk. It does not come into equation when you are committing data.