Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
stascher
Partner - Creator II
Partner - Creator II

Strange Section Access mystery

Hello,

We're seeing a strange situation with our Section Access that we've never seen before. 

We have a Subjects table in our database with a field (SubjID) who's data type is (PK, int, not null). The values are straight forward. For example: 

SubjID Name
1 Bob Smith
2 Jim Longley
3 Sarah Whitely

 

Our section access query is:

SQL select 'USER' as "ACCESS", upper('MYDOMAIN\MYUSERID') as "USERID", '*' as "GROUP", null as "OMIT", SubjID as "Subject"  from Subjects;

Our application body has the following query:

[Subjects]:

SQL select SubjID as Subject, Name from Subjects;

The above does not work; the table is read but I get no access to the data. However, if I change the above query to the following:

[Subjects]:

Load *, num(SubjID,'0') as Subject;

SQL select SubjID, Name from Subjects;

The above does work. Any idea why the internal representation of the Subject field in the Section Access query would differ from the representation of the same field in the [Subjects] table, such that section access works in one case but not the other? 

 Thanks,

Steven

Labels (1)
11 Replies
marcus_sommer

Normally a section access should behave in the opposite direction and excluding non-matches. If this didn't happens it might be related to the document-option of "strict exclusion" which is mandatory to implement a real access control and not just a kind of usability. At least that's the working in QlikView - in Sense it might be a bit different but I wouldn't be surprised if it's further there.

Beside of this I could imagine that other section access properties may also impact the behaviour. And also the "normal" document properties - I never checked the following but I think it might have an effect.

A section access isn't applied during the reload else afterwards if such stored application is opened again. Then the section access associations are taken like a selection with the difference that the excluded values are directly dropped from the RAM. To compare the section access values against the ones from the data-set the interpretation of the values in numbers or strings as well as the case will be considered.

If now both parts of section access/application are loaded equally but afterwards happens a change of the interpretation-type of the fields it may prevent the matching. Again relating with QlikView and there within the document-properties are options for each field to be handled like they were loaded which is default-option or being overwritten with another interpretation and if it should be persisting. I'm not sure how and where this setting is stored but I wouldn't be surprised if this is directly added to the field-properties and be already applied by opening the application. 

stascher
Partner - Creator II
Partner - Creator II
Author

Looks like this was a bug in Qlik which may have been addressed in their latest release (according to the release notes for Feb2024 Patch 4).