Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi everybody,
Is there any restriction loading NTNAME or USERID fields having '*' values on the previous load in a Section Access table ?
Thank you
Normally the approach should work even by using multiple server. Maybe there is just a small syntax/logic issue like using single-quotes for the variable: '$(that_variable)' or in the way the variable is created (did the value really change on the different servers) or how they is named (maybe there is just a typo). Beside this I think I wouldn't use a variable else just the function like above mentioned.
Another way to get the name of the server or maybe even the whole load-statement is to use a separate include-variable just placed within root-folder of your Qlik environment.
Regarding to your '*' issue - could it be that both loadings happens within the section access area? If yes try it by moving the first load above it and only the resident-load is inside the section access.
- Marcus
I'll let you take a look at the below script and tell me what's your thoughts.
what is the trick concerning preparing the security table outside the section access and call the final table inside the section access ?
I don't really know how section access is technically implemented but there must be at least one essential part within the section access area - and if it's just some kind of indexing to the related fields and fieldvalues - and the final work might be applied after finishing the reload and building the datamodel.
This is a deduction from the fact that an optimized qvd-load within the section access doesn't work because there won't any processing applied on the data else they are just transferred within the RAM.
This could be easily bypassed with adding a where-clause like: where 1=1 to the load which then enforced a processing of the data. Your resident load contained also no further processing and might be therefore also run in an optimized mode (I'm not absolutely sure if a qvd- and a resident-load work in the same way but I could imagine it - only the storage will with hard-disc respectively RAM be different).
This meant such where-clause might be helpful in your case. But I assume that rather your creating of multiple different section access tables at the same time - at least with the noconcatenate load - caused your issue. Maybe they create some kind of synthetic key or circular loops or something else - probably it conflicts in any way.
Therefore my suggestion to build the section access tables outside from the section access area and loading there just the final table with such a dummy where-clause.
- Marcus
Thank you so much marcus_sommer for these clarifications, didn't know about it.. I'll try to add a dummy where clause.
Yesterday my collegue here told me that he was not able to load '*' values from resident loads (in a section access table), but from txt files, from a table, from a qvd it is ok.. I'll also try to confirm this.
On the greyed part, using a dummy where clause (where 1=1) didn't help getting the below script work, but inserting again '*' values on the USERID field (on the greyed part) solved the issue..