dash performance different in different QV servers

[Anonymous]

Hi, QVers,

Today I got notification from a college that in the dash which is hold on the production server, several expression columns show "0".

The dash is a copy from my development server, and these "0" columns in the development server  are all correct. All these columns use set analysis formulas that set in the load script. 

For this issue, I do not know whether it is new or exist from the beginning. As I always use development sever, and I can not remember whether that few columns hold correct data or not during the test stage.

For this issue, I already did some checks/tries like below:

1. I use QV11.20 SR12, and both servers use the same version.

2. There are also some other set analysis formulas used in other columns, but works.

I have no idea how to check this now.

Dose any one has any idea?

I will provide a test .qvw file later if I can duplicate this problem in a new dash.

Thanks  very much~

Zhihong

[swuehl]

Well, this could have multiple causes.

- Are you using section access with data reduction in your application?

- Are you using searches in your set expressions, that might be dependent on regional settings of the server?

For example, if you are using a date ranges search and just using a dollar sign expansion of $(=Today()), this uses the default date format. The default date format might be depending on the executing server (if you haven't set an explicite format), and OS regional settings might be different between servers.

If the default date format doesn't match the field format, your expression probably returns zero.

[Anonymous]

Hi, swuehl,

Thanks very much for your answer.

Yes, I use section access.  You are right. It may related to this! I checked the accounts that have access to specific "NWGROUP", then the data is correct. For example, the user01 with access to CLIENTId is correct. But the data for admin01 with access "ALL" is "0".   Do you have any idea how can I improve this for next step?

My section access script is as below:

Section Access;

LOAD * INLINE [

  ACCESS, NTNAME, NWGROUP

  ADMIN, admin01, ALL

  USER, user01, GROUP1

  ...

];

Section Application;

LOAD * INLINE [

NWGROUP, CLIENTId

GROUP1, 1000001

...

];

And for the set expression, there is no searches (first to know this can be a problem, thanks), it is a fixed string, I also use similar formula for other set variables. Below is my set expression:

set _numA= SUM({<GroupType={'A'}>}numbers);

Thanks again !!!

Zhihong

[swuehl]

How do you have linked the NWGROUP value 'ALL' to the section application table? Does it show an entry for every possible CLIENTId ?

[jonathandienst · Accepted solution]

Is ALL an actual value in NWGROUP, or you mean access to all possible values of NWGROUP?

If you need all possible values, then assuming that all the possible values of NWGROUP exist in the section access table LOAD, change the ALL to * like this:

STAR is *;

Section Access;

LOAD * INLINE [

  ACCESS, NTNAME, NWGROUP

  ADMIN, admin01, *

  USER, user01, GROUP1

[Anonymous]

Hi, swuehl, jonathan,

Thanks.  After change to use "*", it then works!!!

Yes, NWGROUP "ALL" do have the access to all the CLIENTId.  So I guess it is a default for all access like "*". That section access is original from another college. So I did not notice that is the problem. 

Thanks very much~

Zhihong

[swuehl]

Just take care that the star symbol is only a replacement for all NWGROUP listed in the section access table.

If there aren't all NWGROUP values in that table or if not all ClientID values are linked to a NWGROUP, admin won't see every possible ClientID. That's why some prefer a explicite ALL value linked explicitely to every possible ClientId in your section application table.

[Anonymous]

Hi，swuehl,

Thanks for the info. It means if I want the admin account to see data from all ClientIDs, and NWGROUP dose not cover all the ClientIDs, then I must use NWGROUP ALL to link to all the ClientIDs.

Is there  any other simpler way to do this?

Zhihong

[jonathandienst]

What I usually do where I cannot be sure that every possible value of a reduction field exist in the SA table, is this:

// LOAD the user list from some source (INLINE here for illustration)

Users:

LOAD *

Inline

[

    ACCESS, NTNAME, NWGROUP

    ADMIN, admin01, *

    USER, A, GROUP1

    ...

];

// Get the '*' users

ACCESSLIST:

LOAD ACCESS, NTNAME

Resident Users

WHERE NWGROUP = '*';

// Cross join them with the possible NWGROUP values in the model ('Data' table for illustration)

LEFT JOIN (ACCESSLIST)

LOAD Distinct NWGROUP

Resident Data;

// Add the explicit NWGROUP members

Concatenate (ACCESSLIST)

LOAD * Resident Users

WHERE NWGROUP <> '*';

// LOAD this table into SA

Section Access;

LOAD * Resident ACCESSLIST;

// And carry on

Section Application;

You can also use a generic link table, as covered by HC here: Generic keys

[swuehl]

Thanks for the info. It means if I want the admin account to see data from all ClientIDs, and NWGROUP dose not cover all the ClientIDs, then I must use NWGROUP ALL to link to all the ClientIDs.

Is there  any other simpler way to do this?

Hi Zhihong,

I don't think that the approach using ALL is that complicated:

Just use your previous script snippet:

Section Access;

LOAD * INLINE [

  ACCESS, NTNAME, NWGROUP

  ADMIN, admin01, ALL

  USER, user01, GROUP1

  ...

];

Section Application;

LOAD * INLINE [

NWGROUP, CLIENTId

GROUP1, 1000001

...

];

Now you need to take care that there is an NWGROUP value 'ALL' that links to every possible CLIENTId.

I assume that above INLINE table is just a link table for your authorization, and there is a CLIENT table with your unique CLIENTId you are using in your app, which your are loading from your data sources.

All you need to do is concatenate all CLIENTIds to your authorization link table in section application:

Section Application;

AUTHLINK:

LOAD * INLINE [

NWGROUP, CLIENTId

GROUP1, 1000001

...

];

CONCATENATE (AUTHLINK)

LOAD

     'ALL' as NWGROUP,

     CLIENTId

FROM CLIENT.qvd (qvd); // adapt to your CLIENT table data source.

This creates a link to all possible CLIENTId. You can create a filter in that LOAD if you don't want to load all clients or you can do a RESIDENT LOAD of your AUTHLINK table to load the CLIENTIds that are present in that table.

This way you have full control about the context of 'ALL' in your section access table down to the CLIENTId level, no need to trust that NWGROUPs have been defined properly or that these groups are linking to all CLIENTId values.

The final solution depends on what your requirements are, but I believe this approach is not much more complex than using any other solution, including star symbol.