3 Replies Latest reply on May 23, 2018 2:12 PM by Brian Somers

    Preventing data load to a base level member in essbase

    DRMSAM

      Hello Everyone.

       

      We have a requirement where we want to prevent data load to few base level members in a particular dimension. That member has historical data and was in use at some point but is not anymore. We cannot remove it but we also dont want users loading data to it via smart view or any other method. What are our options to prevent that from happening?

       

      Thanks

      Sam

        • 1. Re: Preventing data load to a base level member in essbase
          Brian Somers

          The best way is to put read only filter access onto that member. Alternatively you could use a partition (but if it's only one member that may be overkill) or hold the historic data in another cube and make the member dynamic and xref the numbers from that cube (there may be performance issues). What other mechanisms have you for loading data.

          • 2. Re: Preventing data load to a base level member in essbase
            DRMSAM

            The data comes in from ERP via DW which is an automated process and have no issues, and then there are manual inputs from users via smart view which is where we want to prevent this load. We updated the Alias to communicate that this member is no longer in use, but were wondering if there was a better way. Would putting all those members under a parent and making that parent ~ be a good idea? Seems easy, but not sure what other impact would it have? Also would making the member itself as ~ be a good solution? It would impact historical reporting, but once we've copied that to a history cube, this update will prevent data from getting consolidated up.

            • 3. Re: Preventing data load to a base level member in essbase
              Brian Somers

              Giving members the ~ property will still allow data to be entered, it will just roll up as part of the aggregation if for example you use an AGG or CALC DIM or if the parent is dynamic. If you want to keep the data and have it read only a security filter is the best approach (in my opinion). If data can be entered into other members on the same dimension for previous years or scenarios it should be created on the dimension of those members.