GLTRANS query returns no results

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

Sherry Shimek

Advanced Member

Posts: 43

12/23/2008 11:34 PM

We recently created a new data level security class expanding the data accessible to a current security class., but still not allowing full data access. Lawson data level security class testing passed with no exceptions.

However, due to the intense MS Addins query usage of the users in the two classes we decided to test MS Addins queries. They primarily run queries on GLTRANS.

Queries worked fine in the test environment except for queries of the GLTRANS table. Queries of other tables worked fine. Our testing of trans tables was limited by the restrictions of the other subsystems.

We tried the following:
1) Used and didn't use indexes;
2) Used no criteria and various criteria to get to specific expected results from within Lawson
3) Tried it on two different versions of MS Addins (2.0.3 gave results in all instances, 2.0.5 yielded expected results on tester's log-in, but not the new security class')
4) Queried GLTRANS alone and then with related tables
5) Tried different PC's. The new Security ID fquery of GLTRANS failed regardless of the PC.
6) Moved the security class to Production in case there were patches or other differences in the data regions.

7) Rebuilt the security dictionary by going to a command line and entering the command $bldsecdict -d Prodline

Results: The Test User ID failed on all tests but on version 2.0.3. Not convinced that is the difference enough to go back to that version. Open to suggestions though.

Lawson KB article 69261 notes that queries of tables with SYSTEM fields (which GLTRANS has) may be restricted if process level security is defined only for Process Level security. So we added lines specific to GL company security without any change in results.

Does anyone have any ideas of other things to try?

John Henley

Posts: 3353

12/26/2008 6:02 PM

In between making each change to the security classes, are you doing an IOSCacheRefresh on the portal/web server? What platform/environment are you on? If you are on a recent release (i.e. LSF9 or 8.0.3), you might want to try using the Data servlet vs. the cgi-lawson DME and see if you get different results...since that is ultimately what the Excel query wizard is using.

Sherry Shimek

Advanced Member

Posts: 43

1/22/2009 9:29 PM

Thanks for your help, John. Here are the responses I have so far from our security team.

1) We are doing an IOSCacheRefresh on the portal/web server after each change.

2) Platform environment is Windows and UNIX AIX Environment – we are testing in the development environment.

3) We are using 8.0.3. We are checking with the ERP group about which method we are using
the Data servlet vs. the cgi-lawson DME.

Our next step is to add data level security to include process levels AA-ZZ to ensure all System codes are valid (Lawson KB 74084.)

Any suggestions?

Sherry Shimek

Advanced Member

Posts: 43

1/23/2009 10:03 PM

Adding data level security to include process levels AA-ZZ to ensure all System codes are valid was successful. The line entered included Process Level AA to Process Level ZZ. Using two letters to define the allowed range captured all of the System Codes we use. (See Lawson KB 74084.)

Thank you everyone for your help.

k-rock

Veteran Member

Posts: 142

1/24/2009 12:08 AM

Lawson doesn't use numbers but some companies do. You may want to change AA to 00 or 10.

Sherry Shimek

Advanced Member

Posts: 43

1/27/2009 10:34 PM

Thank you for your response as you are right on target - we use alpha and numeric characters in our sys codes. As provided in the system code list, the range is A1 through Z2. However, would that range include all system codes with two alpha characters?

k-rock

Veteran Member

Posts: 142

1/28/2009 8:10 PM

Yes, computers treat numbers as appearing before letters. You should use A1 through ZZ.