Security - Section Access from qvd

[#1]

Hi,

I am trying to implement section access code in my qvw by extract data from qvd file.

I am getting error while running this.

Can section access read from qvd files?

Thanks,

Clara

[g_westaway]

Hi,

I came across the same thing, in the end I just loaded the qvd BEFORE the Section Access statement, then there I reloaded it with the 'resident' clause and dropped the original.

I hope this helps.

Giles

[Miguel_Angel_Baeyens]

Hello Clara,

It does, actually, although you need to make sure that the loading is unoptimized, meaning

LOAD ACCESS, USERID, PASSWORD FROM SA.QVD(QVD) WHERE 1=1;

Hope that helps!

[amien]

@Miguel Angel Baeyens Thanks

Do you understand why this is needed?

[Miguel_Angel_Baeyens]

Hi Amien,

I don't know the architecture behind the section access and the unoptimized load. My guess is that it's something similar to what happened with mapping tables (what by the way, has been changed in version 10 where a mapping table can be loaded directly from a QVD file optimized and that works).

I sent a mail long ago to QlikTech's Gustav Guldberg (author of the most successful section access how to in the Documents area) regarding the need of unoptimization (which, at the time, was not stated in that document) but I got no answer. Maybe it's worth a new try.

Regards.

Miguel Angel Baeyens

BI Consultant

Comex Grupo Ibérica

[ToniKautto]

That is correct, the QVD load is required to be unoptimized to enable loading a section access table. Usually the Section Access table is quite small so the compression and speed benefits of a QVD will not make much difference, hence the unoptimized load will not generate any performance loss.

I can not answer the exact reason for why unoptimized load is need, but a guess is that the section access table is stored in a different manner than a regular table and therefore an optimized load would not fit that requirement. There is no known bug registered for this scenario, and I do not hink there is much point in reporting one either as this would not be a high priority to change. I will however look into if this could be a documentation bug, so that the unoptimized requirement is specified clear enough in the manual.