If your aim is to block the SQL*Plus user from seeing data one of the following can be tried (though i myself have never attempted them) 1. VPD (attach a predicate where rownum < 1 OR where 1=2 that way no row will get selected) 2. Use Product user profile and try to block SELECT/INSERT/DELETE/UPDATE hth GovindanK On Fri, 14 Oct 2005 15:10:14 -0400, "Vanessa A. Simmons" <vsimmons@xxxxxxxxxxxxxxx> said: > We are considering a change to the way our users access the database and > our applications. We would like to make sure that users are getting to > the data through the applications only and not using external tools > (i.e. SQL*Plus) to access the database directly with the hopes that this > will help us to further secure our databases. In this scenario, we would > create a high-level user which would be the data source user (we're > using Cold Fusion for our application front-end) that would be able to > run any query on behalf of the user "logged in" to the application. > However, each user would not have his/her own DB account that requires > role and password maintenance. Instead, the programmers would create a > user and role table in the database that would hold this information > (including encrypted passwords) so that the users do not have individual > access to the database. That would push a lot of the user maintenance > that I deal with on a daily basis to either our programmers or a help > desk technician. > > My question is whether or not this is a sound plan and if you have any > concerns about problems we might encounter if we decide to go this > route? Has anyone else done something similar in their environment? -- //www.freelists.org/webpage/oracle-l