topic Re: Work around for wildcard in data reduction? in QlikView

Work around for wildcard in data reduction?

Tue, 13 Jan 2015 22:00:16 GMT

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.

Re: Work around for wildcard in data reduction?

jpapador — Tue, 13 Jan 2015 22:26:31 GMT

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.

Re: Work around for wildcard in data reduction?

Tue, 13 Jan 2015 22:32:41 GMT

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...

Re: Work around for wildcard in data reduction?

jpapador — Tue, 13 Jan 2015 22:34:13 GMT

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?

Peter_Cammaert — Wed, 14 Jan 2015 02:01:51 GMT

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

Re: Work around for wildcard in data reduction?

Wed, 14 Jan 2015 02:15:20 GMT

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?

Peter_Cammaert — Wed, 14 Jan 2015 02:27:19 GMT

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