Qlik Community

QlikView Scripting

Discussion Board for collaboration on QlikView Scripting.

Highlighted
Not applicable

Work around for wildcard in data reduction?

I have developed an application that contains several clients data within it. I am trying to use Section Access to determine which org units to load. Org units change and, rather than constantly going into the table and adding and subtracting units, I was hoping to use an asterisk as a wildcard since their is a naming system in place (numbers leading by a client abbreviation). After some research I've learned that wildcards will not be recognized. Is there a work around?

Example:

Org Units

MIC - 001

MIC - 002

APP - 045

Section App:

MIC*

APP*

I've tried to use section access/application to data reduce a client field. Then in another table have a list of clients and their org unit abbreviation + wildcard.

Limit      Client

1               *

2              Microsoft

3               Apple

Client:         Org Units

Microsoft     MIC*

Apple          APP*

However this results in the user seeing everything.

6 Replies
Partner
Partner

Re: Work around for wildcard in data reduction?

I think you can use a wild card (*) in section access but you have to define it first.

The very first line on your section access tab you have to define STAR is *;

I don't think you can use it for key fields but it might be worth a try.

Not applicable

Re: Work around for wildcard in data reduction?

It works in section access, but does not work in combination with other characters. So * will count as everything, but MIC* will be read as 'MIC*' instead of MIC...

Partner
Partner

Re: Work around for wildcard in data reduction?

Right, I think once you define what your STAR is , it will act as a wildcard instead of a character but I don't think they let you use wildcards in fields that link to other tables.

Re: Work around for wildcard in data reduction?

Exactly, * can be used as a wildcard in section acess only by itself.

A workaround is to use MIC* in Section Access, and to create a Link table in Section Application that expands MIC* into all values that start with MIC. For that table, you don't need to know what's in the Link field in Section Access. Just create a Link table based on [Org Units], like:

Section Application;

LinkTable:

LOAD DISTINCT left([Org Units], 3) & '*' AS LinkField, [Org Units]

RESIDENT / FROM Source Data;

and now include LinkField in your Section Access Table; They will meet allright.

Peter

Not applicable

Re: Work around for wildcard in data reduction?

I ended up doing something similar to this.

I created the CLIENT field in the ETL using: Left(Org Unit,3)          AS CLIENT,

Then:    

Section Application;

Permissions:

  LOAD

       CLIENTLIMIT,

       CLIENT

     

  FROM Security;

Worked for me. I assume it is pretty much the same result, just spread out in different applications.

Re: Work around for wildcard in data reduction?

You're right.

With this little difference. If you want to make your Section Access configurable by reading an external file, you'll need to read it twice (once in section access for IDs and ClientLimits, and once in Section Application for reading the combination of ClientLimit and Client). In my example, only Section Access will use an external file detailing User IDs and LinkField values. The rest is extracted automatically from the data.

Good luck,

Peter