topic Re: Strange Section Access behavior in QlikView

Strange Section Access behavior

Mon, 26 Jan 2026 18:19:17 GMT

For some reason, the Section Access Security works fine with a basic user id from C drive.

When the file is moved to root drive of web server, that same ID will get deined.

Seems to me there is something Qlikview is looking for to keep that user ID with combination of drive location (or web root dir) to deined.

Is this tracked in registry or file somewhere that can be cleared?

I have tried creating a new app by beginning with the backup copy with no section security.

Tested it in C: and works.

Tested in root drive fail.

Also, for unknown reason, opening of the app via web using that Section Access ID will fail. However, not all other "basic" users will fail, liked ADMIN and some other USER .

Why?

Re: Strange Section Access behavior

Thu, 23 Jun 2016 21:14:14 GMT

btw, i have notice if I comment out the LoAD block after the

Section Application:

LOAD *[

...

then the basic user login will work fine. That is the login window will comes up.

Once uncomment the LOAD block under section application, reload, save, that very same basic user login will get a deined when login.

why?

Re: Strange Section Access behavior

Peter_Cammaert — Fri, 24 Jun 2016 16:06:56 GMT

Well the intricacies of Section Access are not very easy to explain. At the risk of not making myself particularly clear, here goes:

If you use Data reduction based on section access ,and there is a connection between section access and section application, then the resulting data set after data reduction will determine whether a user is granted access. No data remains after data reduciton = no access.
If you use Data reduction based on section access, but there is no link between section access and section application (because of being commented out), then the section access table will only be used to look up users with access to the document. Data reduction will not have any effect.

Best,

Peter

Re: Strange Section Access behavior

Fri, 24 Jun 2016 16:11:07 GMT

That's actually very helpful.

The strange thing is when I'm using an ID that hasn't been used by my app before, opening from web root dir will also denied it.

Is there a place to reset the ID?

Re: Strange Section Access behavior

Peter_Cammaert — Fri, 24 Jun 2016 16:29:01 GMT

The data in your section access table is only refreshed during a reload. So how would Section Access know about a user that has "not been used by my app before"?

BTW Is your Section Access using NTNAME or USERID to identify users?

Re: Strange Section Access behavior

Peter_Cammaert — Fri, 24 Jun 2016 16:30:25 GMT

"That's actually very helpful". Ok...

Helpfuls can be marked as such using the corresponding item in the Actions menu. Thanks.

Re: Strange Section Access behavior

Fri, 24 Jun 2016 21:05:57 GMT

Section Access is using USERID

"So how would Section Access know about a user that has "not been used by my app before"?"

Yup, strange, indeed.

It seems as if the USERID used in this brand new app is generic enough that it is known by the "Reducer's" Section Access to denied.

How to clear it?

Re: Strange Section Access behavior

Peter_Cammaert — Sat, 25 Jun 2016 19:09:42 GMT

From your second post I get that the login window doesn't appear when you try to open the document in the AccessPoint? It only appears when you comment out the Load of the link values in Section Application?

Re: Strange Section Access behavior

Sat, 25 Jun 2016 20:53:50 GMT

The login window comes up and deny the user, at access pt when the LOAD statement is not comment out.

It prompts user for password when commmented out the LOAD block.

And there is data for the USERID to browse.