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

Looking for Seurity Tables

1 Replies

0 Subscribed to this topic

24 Subscribed to this forum

Sort:

Author

Messages

SSecora

New Member

Posts: 0

2/8/2007 8:37 PM

I need to write a report against the security tables, but I can't seem to find the names/locations of the security tables. I am very new to Lawson (and Crystal), so I hope that this isn't a stupid question.

Specifically, I need to compare security class against the employee's RD30 record, which I've found on DBLOWUR. We're running an I-Series/AS400 on the back-end if that makes any difference.

Thanks in advance for your help.

John Henley

Posts: 3366

New Poster

Engaged Reader

Avid Reader

2/8/2007 9:37 PM

No question is too stupid, particularly when it comes to Lawson!

I can't speak specifically for iSeries/AS400, but (at least pre-version 9) on Unix/Windows the answer is you really can't do it with Lawson-delivered tools, since that data is stored in the GEN (non-relational) database. The reason is two-fold:
1) Since the security tables are part of GEN and not in a relational database you can't use a native SQL driver to get it, and
2) if you were to try to use Lawson's OLEDB provider, you'd probably find out that the GEN product line/tables are not exposed.

Since you have LOGAN table DBLOWUR (WEBUSER in Unix parlance), that tells me you are not running LSF9. When you get to LSF9, GEN moves to a relational database, and you will be SQL SELECT against the SECCLASS table to get what you're after.

So, where does that leave you?

While you can't use Crystal (via the Lawson OLEDB provider) to access the GEN data, you CAN use rngdbdump (or DME [browser] queries) against the GEN data and save to a CSV file. You could then have your Crystal report include that CSV file as a data source. Not the most elegant solution, but since security classes fairly static, it's not all that bad...