Best Of

Hi Etienne CAUSSE Firstly, like Davide Genini, I do not think I understand fully Hervé BEURET requirements. The reference to a multiple database model was to respond to a percieved requirement to prevent the user from circumventing security and seeing what they should not. Secondly, I did not read the complete exchange between Hervé BEURET, Davide and yourself as I was responding on the train using my phone. - Sorry for adding to any confusion.

My first point hasn't changed.  My response is based on an assumption that Hervé BEURET needs to restrict access to entity members for specific users. If this was the intention, then a single db and capsule can be used but the control must also be incorporated throughout the database architecture.

I develop models for external clients that share a database. The security is handled in the way you have already described but also with a matrix mapping cube. Db security is set as follows where a client user group are restricted to seeing data on for client number 1:

Sample entity: PROPERTY > PORTFOLIO

Code + Desc

1 - Client 1a

2 - Client 1b

3 - Client 2a

4 - Client 2b

5 - Client 2c

@user
SELECT CLIENT = 1
SELECT [SECURITY_CLIENT_PROPERTY]=1
SELECT [SECURITY_CLIENT_LEASE]=1
SELECT [SECURITY_CLIENT_EVENT]=1

NOTE:

1. Entities CLIENT and each of the mapped entities are all duplicates and share the same mapping using the mapping cube.

2. Each tree datareader (Property, Lease and Event) contains the relevant SECURITY entity.

3. Each Cube datareader contains only the entity CLIENT - which has been mapped to the SECURITY entities and a single matrix cube.

With the above configuration, I am able to control what members of shared/common entities each, disparate client, can see. I also secure the cube values that they have access to.

users with this config would see only:

 - PORTFOLIO entity members for the first 2 members (1 & 2)

- Cubes would only show values / entries mapped to the PROPERTY / LEASE / EVENT for client 1

- GVA Analysts will see all entries and can simply select CLIENT 1 to see exactly what the external client sees

The use of the mapping cube means that GVA analysts can have unrestricted access to the database and select the CLIENT or CLIENTS they wish to view.  Using a procedure to select the SECURITY ENTITYs based on the Mapping cube, internal analysts can work in controlled and secure stable data structures relating only to what they need.

Now, it is probable that I have completely missed the point and if this is the case I'm really sorry. However, in the event that I assumed correctly, then I have at least suggested that it is possible to control access to entity members without using the local dataview/object configurations.

It is my intention to demonstrate this structure at some point, once I have the time to create the test model, video and screen shots.

Hi Adam Elvin.  Accepting that there are many things that will result in errors such as the invocation one, the commonest reasons that I've encountered errors of this nature has been as follows:

1.  Entity or Cube removed but reference remains in datareader resulting in error on running reader.  Usually spotted through error on re-running dataload process and having a message in bottom right of screen - hard to see on a 27" UHD monitor. 

2.  Screen left open when database work was carried which deleted/altered an entity or cube used in a dataview/chart object.  This also resulted in a corrupt capsule in which it was impossible to delete said screen.  I had to re-name the screen 'DO NOT USE' and rebuild the screen.  The capsule is still carrying this corrupted screen.

I'm not claiming that the 2 points above are what has happened to you, just that you might want to consider what changes you've done and maybe check for messages.

Adam Elvin, that's a great outcome and thanks for sharing it.  You've linked the error to a domestic task that we, as analysts, are constantly involved with - housekeeping.  As such, we are all capable of falling foul of this error at some point. 

I for one would never have considered the re-installing of BOARD to rectify the error; instead, I would have completed a ticket and awaited the assistance of a superhero from BOARD SUPPORT - my own beingVasili Aravidis.  After reading your response and learning that it resolved the issue, and after all else had failed, I would now have no concerns with carrying out a re-install at an opportune moment.

Hi Kelly,

I am firstly assuming that:

1. Steps to calculate moving average have been carried out separately.
2. Moving Average values have been stored in the temp cube.
3. Temp cube values need to be transferred to the target cube against the correct devices and date of capture?

Does your procedure first select the current day dynamically before writing the contents of the temp cube to your target cube?  If not, you would be writing the new values over the top of all values and across all dates.

If what I've described is true, I am guessing that you you would need to select the date against which you wanted to store the temp values in the target cube.  Using a procedure, your process could look like this, where measures is the target cube:

A breakdown of the above 2 step procedure could then be as follows:

1. Selection

2.  Data flow 

   Block a.   Temp cube: 1D - Device

   Block b.   Target cube: 2D - Day, Device

   Dataflow: Target cube = a

HTH

Kind regards,

Paul Wyatt

Thanks for your help Bjorn. I will now raise it with the support desk.

Can I take it from your reply that the screen sizing feature is working as expected for you?

For completeness, I created a brand new capsule with a different database

   -   One screen only. 

   -   No masks

   -   No screen setup in any way

Same outcome when selecting 'Fit to page':

Image: Yellow area indicates the amount of screen lost when selecting 'Fit to page'

If Björn Reuber is getting a successful outcome with this feature but other users are able to document adverse outcomes, it should be understood under what conditions the features operate as designed.  This can only be described by BOARD Intl.

There are functional issues with this and a number of the new features of BOARD 10.3, features that were presented at BOARDville promising that developers needed only to wait for the release and not waste time fixing or mitigating functionality that has become native. 

For test script purposes, the release notes describe the expected behaviour of the new features and so it is very simple to evaluate this and the other new features.  

As I cannot switch off these features, I cannot recommend that GVA upgrade to BOARD 10.3 as we have external customers to whom we would have to explain the issues, and admit where we did not know the solutions to such platform features.