>I also have a users table where I set up levels of access -- edit, read only, admin. The last field of that table is an integer field where I store a check sum value based on the sum of check sum values of the the data in the other fields. So if the data is hacked for a specific user, it is most doubtful they will be able to guess the new check sum value. If that happens that user automatically gets demoted to read-only until an admin person fixes the problem.
>

Ok, it sounds like what I've been doing is along the right track. I've always had a user table, which would usually store the basic user info, password, etc. Lately I've taken things a few steps further. My last app includes using an appsec table (stores all the possible app security rights) and a userprofile table which stores the rights that each user has. Currently each right is either .t. or .f., but I may expand on that a bit.


>
>For Oracle, I have my own user login form that prompts for their Oracle ID and password. Once they connect, I have an Oracle table of users where I check what privileges they have. We also have a generic Oracle ID and password that we use to connect behind the scenes to retrieve user and login info if needed.
>

Since I've only started delving into Oracle, I have no idea on the usual way that DBA's want things done. Do they want to have to set up every user with their own Oracle ID? If so, how do you know which schema your data and the users will be put in?


>I store the user's access privs in a global application object -- goApp.UserPrivs. My form data entry controls have in their init some code that checks this value and sets the ReadOnly or Enabled property accordingly. I also have a property on each control to toggle this checking on or off.
>

I too use a oApp.Security object. I write all the user rights to properties when they login. Of course, if their rights get changed, they have to log out then back in for the change to take affect. Some have complained about this in the past, but I'm not sure how to have the change take affect while they are logged in.

Some of my checks are done at the menu level instead of on the form, at least for overall form access. You mention doing some of the ReadOnly check for controls in the control init. Does that create a lot of overhead when opening complex forms?


- Brian