I'm trying to use section access on more than one table, with one table requiring row-level filtering and the other requiring column-level. Both work well independently, but when I have both section access statements in my script, they seem to interact and I see synthetic keys being created on fields like ACCESS, USER.EMAIL, and GROUP during the load. My understanding was that the section access tables don't persist after the section application is loaded, but they definitely seem to be interacting in some way. Does anyone have suggestions? A bit of sample code is below:
SECTION ACCESS; Load * INLINE [ ACCESS, USER.EMAIL, GROUP, REDUCTION ADMIN, xx@xx.com, *, * USER, *, a, a ];
Section Application; [Table1]: LOAD * from [table1.qvd](qvd);
Hi, I don' think you need two Section Access tables for this, as row reduction and column omission can be handled in the same SA table.
Just add OMIT to the first table and define both REDUCTION and OMIT for the relevant user/group. Something like this:
SECTION ACCESS; Load * INLINE [ ACCESS, USER.EMAIL, GROUP, REDUCTION, OMIT ADMIN, xx@xx.com, *, *, USER, *, a, a, b];
The synthetic key you are seieing is probably because the two Section Access loads create separate tables sharing ACCESS, USER.EMAIL, GROUP and REDUCTION.
There's also a useful example in the documentation under the 'Managing access to the column-level data' section:
Hi, I don' think you need two Section Access tables for this, as row reduction and column omission can be handled in the same SA table.
Just add OMIT to the first table and define both REDUCTION and OMIT for the relevant user/group. Something like this:
SECTION ACCESS; Load * INLINE [ ACCESS, USER.EMAIL, GROUP, REDUCTION, OMIT ADMIN, xx@xx.com, *, *, USER, *, a, a, b];
The synthetic key you are seieing is probably because the two Section Access loads create separate tables sharing ACCESS, USER.EMAIL, GROUP and REDUCTION.
There's also a useful example in the documentation under the 'Managing access to the column-level data' section:
The section access tables are a mandatory part of the data-model because they define by opening the application the next time which data should be available for the given context (mostly the user).
I never tried to place several ones and therefore I couldn't say which impact it may have but like already suggested you could combine row/column level access control within a single table.
Thanks! This is what I ended up landing on and it worked well. I just couldn't find any documentation on how to manage section access on 2 different tables with different requirements, so took some trial and error.
