> This is what we want to do > * One database > * Most users (Companies) cannot view > each others information > * Select users can view the entire database > * Access to the files happens via all available > interfaces (i.e. not just green screen) While the subject says 'row level security', the description sounds more like you want to segregate Company A's data from Company B's users, etc. Going on that assumption, the classic way to use OS/400 security to do that is to make AUT(*EXCLUDE) on the current PF and create an LF for each company. Grant authorised users authority to the logical (company) they can see, and OVRDBF after your selection to point to the 'right' one. This presumes that user Buck doesn't need to see records from company A, B and C at the same time, but he can see them one after the other, viz. Select A, CHKOBJ, OVRDBF, see A. Select B, see B. Another way is to restrict all authority to the PF and create an API that all code must call in order to read the data. The API validates that the user is able to access the record she is requesting. That API can be implemented as a stored procedure for the ODBC/SQL people, or as Scott notes, a read trigger for V5R1. That eliminates bulk transfers like FTP and Client Access. The good thing about stored procedures on our platform is that the SP is an HLL program. So the same program can serve green screen or SQL clients. --buck
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.