This is a companion post to the article KB 000004090
1) In order to function properly in Desktop as well as server environments, two separate ADMIN entities must be defined: the first one is associated with an empty string (or any string that does not match data in the reduction field), and this entity (typically a Publisher machine) is used for reloading the application data, but this entity cannot open the application in a server environment (as designed). The second ADMIN entity is associated with an "*" in the Section Access part of the script and is never allowed to reload data, but is on the other hand allowed to view all data in a non-reduced state on the server as well as desktop.
2) The initial table must NOT contain any record regarding the first ADMIN entity mentioned in (1) above, since this entity must be able to refer to a reduction value that is NOT a part of the logical data table outside the section access area. This entity must ALWAYS be defined in the section access area and nowhere else.
3) The initial table must be dropped in order to avoid collisions between reduced and non-reduced data in the section application, otherwise, the strict exclusion flag will prevent any access to the server document. This is as designed, a bad reduction is always supposed to fail any attempt to log in on the document.
Assigning an ADMIN level to an entity that is subject to data reduction is NEVER a good practice and should be avoided, such an entity should either be elevated to full ADMIN level and consequently not subject to any data reduction or demoted to USER level (this is usually the most plausible action).
It is strongly recommended that the initial table is dropped, since this table is not fully reduced and does not contain all records that are part of the section access area (see #2 and #3 above) and, consequently, will not function as a proper link table to the logical data structure in section application (see modified example where a link table is defined based on the table in the section access area rather than the initial table).
4) It is possible to use Groups in section access (from an AD for example). They are added in the exact same way as users under NTNAME. When mixing users and groups in section access extra care needs to be taken with the permissions. If a user is present as both an individual user and a group member you should ensure they have the same permissions in both cases.
5) Do not have an Active Directory Group named as the service account running the QlikView Services. Any user member of this group will get the same privileges as the QlilView Service account (Usually Admin privileges)
6) Ensure the Strict Exclusion setting is checked in the Settings\Document Properties\Opening tab settings of the application if data reduction is being used.
Please see the QVW attached (SA_EXAMPLE.QWV) for a script example. Section access user ID and credentials are set as following:
UID, PWD, Description:
A, A, Reload only - no server access.
ADMIN, ADMIN, No reload - full server access.
AAA, AAA, No reload - limited server access.
B, B, No reload - limited server access.
C, C, No reload - limited server access.
BFS, BFS, No reload - limited server access.
BHX, BHX, No reload - limited server access.
BRSGH, BRSGH, No reload - limited server access.
