Work around for wildcard in data reduction?

[#1]

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.

[jpapador]

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.

[#3]

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

[jpapador]

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.

[Peter_Cammaert]

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

[#6]

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.

[Peter_Cammaert]

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