binary and section acess?

[Anonymous]

Hi Folks,

Intersting scenario:

I have  2 dashboards called

TEST.QVW

TESTNEW.QVW

I have taken test.qvw application through binary into TESTNEW.QVW

so now binary statement is going to be a first statement ..

now I have started applying section access on TESTNEW.QVW  when I started writing code in hidden script

that hidden script tab will move to the first place

my doubt is when I write section access code it will move to the first place and binary will be in second tab .

in this case how binary is working ?

binary should be always in first tab  I mean to say first statement in the script level

in this case first statements are going to be section access code then how binary is going to work here ?

Any special reason on this ?

[alexandros17]

Write section access in TEST.QVW (do not enable section access when you publish it) then inherit it into TESTNEW.QVW.

I use always this logic and it works.

[marcus_sommer]

The solution is that the qvw from where you loaded binary must have already implement the section access. For me it worked very well with a 3-tier approach from:

1. Generator

2. Datamodel with Section Access // loading various tables from Generator and other sources

3. Report with Section Access // loading binary from the datamodel

Edit: in bold

- Marcus

[Anonymous]

can u give bit more explination

[Anonymous]

I am also following same structure

only thing is section will be in first tab then second tab is having binary

then how it is working

[maxgro]

- binary must be the first statement in the .qvw

- when using binary section access is inherited

this is from QlikView help

Binary

The binary statement is used for loading the data from another QlikView document, including section access data. It does not load the layout information or variables. Only one binary statement is allowed in the script and it can only be put as the first statement of a script

Inherited Access Restrictions

A binary load will cause the access restrictions to be inherited by the new QlikView document. A person with ADMIN rights to this new document may change the access rights of this new document by adding a new access section. A person with USER rights can execute the script and change the script, thus adding own data to the binary loaded file. A person with USER rights cannot change the access rights. This makes it possible for a database administrator to control the user access also to binary loaded QlikView documents.

[alexandros17 · Accepted solution]

What Marcus Sommer is saying is correct,

You need to write your section access in the original document then the second one (the one with binary load) will inherit even the section access code.

[Anonymous]

then

TEST.QVW IS HAVING SECTION ACCESS

LOADED THROUGH BINARY INTO  TESTNEW.QVW HERE ALSO I AM HAVING SECTION ACCESS

NOW IT WILL LOAD PROPERLY OR ANY ISSUE WILL BE THERE?

[marcus_sommer]

Before going further make BACKUP's. Another important point is to use strict exclusion within the tab open, see also: Section Access and then you will need to try it with a testfile with file-access only to you and some other test-user to check if logic and the data-quality are working properly.

- Marcus

[Anonymous]

If your users access to the Apps with AccessPoint only and you can load user rights from another source, you don't need the hidden script. Our Datamarts (Test.qvw) always are without SectioAccess.

In the Front-End qvw (Testnew.qvw) you make binary import and afterwards enable SectionAccess.

If you want to update SectionAccess without update the data, you don't have to load the datamart at first. You can load Front-End only.

No problem, you can see this script too.

BINARY $(include=..\3_Include\binary.txt);

$(include=..\3_Include\connection.txt);
OLEDB CONNECT TO $(vConnectionString);

Section Access;

SECURITY:
LOAD
UPPER(ACCESS) as ACCESS,
UPPER(NTNAME) as NTNAME,
Upper("FREIGABE") as FREIGABE;
SQL SELECT *
FROM dbo."V_R_PROZESSANALYSE";