|
-- -- [ Picked text/plain from multipart/alternative ] Well... yes Rob, you're right. Thats why I decided I'd better be listening to the folks on this list. The problem is one of those trivial things that becomes a dark cloud of misery for months afterwards. --------------------------------------------------------- Booth Martin http://www.MartinVT.com Booth@MartinVT.com --------------------------------------------------------- -------Original Message------- From: midrange-l@midrange.com Date: Thursday, January 24, 2002 03:49:00 PM To: midrange-l@midrange.com Subject: RE: Use of a trigger...? is this areasonable? Well yes, but you will probably have to change pert near everyone of your existing programs - don't you think? Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin "Booth Martin" <Booth@MartinVT.com To: <midrange-l@midrange.com> > cc: Sent by: Fax to: midrange-l-admin@mi Subject: RE: Use of a trigger...? is this areasonable? drange.com 01/24/2002 03:22 PM Please respond to midrange-l -- -- [ Picked text/plain from multipart/alternative ] But Rob, isn't that the whole point of field level security? So a programmer can't just start DFU and read the President's salary and Y-T-D fields? Isn't it supposed to stop on every record? --------------------------------------------------------- Booth Martin http://www.MartinVT.com Booth@MartinVT.com --------------------------------------------------------- -------Original Message------- From: midrange-l@midrange.com Date: Thursday, January 24, 2002 03:12:19 PM To: midrange-l@midrange.com Subject: RE: Use of a trigger...? is this areasonable? Richard, Think of it this way. You have a traditional RPG program. You loathe selecting fields with logical files or SQL. Now you read a file which contains a field of which you are not authorized to - by the way it is this field for every record. Therefore every read will be an error. The workaround is to either create a view or logical file which omits these secured fields, or avoid traditional RPG i/o and use SQL to if superuser; cursorstmt=Select keyfld, dtafld,secfld from myfile; else; cursorstmt=Select keyfld, dtafld from myfile; endif; c/exec sql c+ prepare curstmt from :cursorstmt c/end-exec c/exec sql c+ execute curstmt c/end-exec plus the matching logic for the fetch statement. Get the gist? Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin "Richard B Baird" <rbaird@esourceconsu To: midrange-l@midrange.com lting.com> cc: Sent by: Fax to: midrange-l-admin@mid Subject: RE: Use of a trigger...? is this areasonable? range.com 01/24/2002 02:49 PM Please respond to midrange-l Am I crazy, or didn't I hear something about "field level security" being a new feature on the 400 several years ago? I've never used it, never seen it used and I heard it had a fairly significant performance hit. if true though, couldn't that be used for your ferpa problem? ok, maybe i am crazy... rick ---original message--- This is an existing application with lots of existing programs and queries. The records are (and should be) available for totaling, counts, reports, and internal use. FERPA has to do with releasing private information to the public. Creating the new logicals is a solution of sorts but creates many problems with day to day use of the data. The issue isn't so much security as it is "appropriate use". Some sort of as-yet undefined business-rule process has to take place. There are people already working on solving the business rule problem but my task is to implement the business rule once they've written the rules. It appears to me that I have to find some way to attach the business rules to the data itself, not overlay a simplistic mask on the data. A logical view solution seems easy to implement but impossible to live with. Thank you all for this discussion. Its being very helpful to us here. _______________________________________________ -- [ Content of type image/gif deleted ] --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.