....

[Access]

My users are totally dense, there isn't a chance in hell any of them
are going to create another adp and connect to this database. I just
don't want them getting a nasty odbc error that might make them cry.

My security is basically each role has read/write to all tables and
then I explicitly do a deny select, delete, insert and update. Some
tables the deny update is at the column level.

I was thinking of just creating a table which would be populated by
the results of this stored procedure

sp_helprotect

The tag property on the form would be the name of the underlying
table. I could check the security table for the table listed in the
form tag on open and change the behavior of the form to match any
denies at the table level and then loop through the controls and check
for denies at the field level.

That would work. If I changed permissions I would only have to delete
my security table and repopulate it using sp_helprotect.

I agree with you about adp. It really stinks that you can't give
permission to views without giving permission to the underlying
table. You can give permission to views and not tables and link to
the view with an mdb and it works fine.

The other problem I have is this Access will crash every once in a
while and when it does the file becomes corrupted. Just lucky I keep
lots of backups. Never had that problem with mdb's