Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
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.
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).