To add to what Kelly said, this all depends on how secure you want the DB to be. You can go from every user having their own Oracle ID to just connecting as the DB owner. Then you have the SP-only advocates and just granting EXECUTE privileges only on these SPs. This is can be a PITA, but at least Rod Paddock has a DataClas that will create scripts for all your tables that will create the SPs for you. If you don't go the SP way, then you have to grant INSERT, UPDATE, DELETE and SELECT privileges on all the table to either a Role [good] or each user [bad]. Roles are better because you grant the privs to the Role only once. Then grant the appropriate Role to a user. Otherwise, if you add a new table or change your mind about privs, you only have to modify the privs for the Role and the users that have been granted that Role are "fixed" with no hassles.

Personally I prefer connecting as the DB owner within the app as Kelly talked about and NOT using SPs only. I do not have to prefix tables with the schema name, I do not have to deal with privs on the DB side. You can get as creative as you want with how you set up who can do what. I do this with a user access table in Oracle.

Since I do this, I also do not have to deal with keeping up individual IDs and users screwing up passwords, etc. They also can not use MS Access or some other hack tool where they could use their Oracle ID and Password to screw with the data outside my app. This is my compromise between minimal security and maximum [SPs only] security.

>Thanks Kelly,
>
>This actually makes a lot more sense now...
>
>This is just a test for me to see if I can get to work with the oracle provider. I'm trying to get my bus objects to work with it, and it works with the exception of the database prefixes which screws with my 'tablename'...
>
>I may have to rethink this and add an optional DataBasePrefix and embed that into each command as needed...
>
>Pretty lame that you can't select a data base directly, but with the Logon at least I might be able to test. Don't know if that is a realistic requirement though - you wouldn't want to have everybody logging in as the 'owner' fo the database...
>
>+++ Rick ---