Skip to Main Content

Analytics Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

HE641 Loading Extract

770916Jun 11 2010 — edited Jun 14 2010
While attempting to reload an extract in Hyperion Enterprise 6.4.1, I get multiple messages. Can anyone help me decipher their meaning? I am pretty new at this.
Here they are;
Line 67: Invalid security class CAT_ACTUAL. – Confirmed not in CEStst app.
Line 102: Module Organization: Cannot lock Entity Load.
Line 151: Module SubNodesByPer: Cannot lock Entity Load.
Line 192: Module Organization: Cannot lock Entity Load.
Line 4470: Module Entity Load: Category is required to load Ownership by period.
Line 42332: Module Entity list load: Cannot lock Organization.
Line 45005: Module Accounts: Cannot lock Organizations.
Line 51985: Invalid security class ENTITY_PFR.
Module Application Load: Cannot lock Organization.
Line 52683: Module Organization: Cannot lock ASCII Load.

Comments

gerardnico
Just create two answers and give them the authorization to only one group.

You will end up with:
- one answers at transaction level for the standard group
- one answers at total level for the standard group

Cheers
Nico
user11440683
This is currently my workaround solution, but I dislike it for maintenance / enhancement reasons....


thanks for your input though,


Robert.
gerardnico
You have an other solution which is the audit.
Just add a hide column to get the user and add it in your SQL statement.

I prefer audit than to implement security.
You have more flexibility.

Cheers
Nico
user11440683
Hi Nico,


what do you mean by 'audit'?


From what you expand, am I presuming that you mean I; -


1. Add a column that gets user name or user group to ascertain if user should be allowed writeback
2. Hide column

And then still allow postback (yes?) but itercede some logic that picks up the hidden user / group value and IF group user = allowed THEN continue as normal ELSE do nothing??

Is this what you mean, if not then kindly explain audit??


regards,

Robert.
gerardnico
Answer
I mean:
- add a column in answer with the name of the user
- add a user column in the target table
- use it in your writeback SQL statement to update it

You can then know who is the last user who has updated the data.
You can also add a trigger on the write back table to seed an history table.

no IF THEN ELSE/security logic, just an audit to know which user has updated the data in case of
conflict or just to give a better formation.

Cheers
Nico

Edited by: gerardnico on Aug 23, 2010 10:51 AM has and not have
Marked as Answer by user11440683 · Sep 27 2020
user11440683
Ok.

Thanks for your input and clarification.

In this case the users should not be allowed this level of input so prohibiting the behaviour entirely is my only option, but I understand where you are coming from...


thanks again,

Robert.
gerardnico
If you want, you can implement the security in the trigger ;-)
But it's more work and not very maintainable.

Success
Nico
1 - 7
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jul 12 2010
Added on Jun 11 2010
2 comments
1,225 views