Locking Tables

  • Thread starter Thread starter DS
  • Start date Start date
in message:
Is there anyway to lock a table so that no more records can be added?

Yes and No are the correct answers.
Yes you can limit the number of records in a table by using some code and
never allowing users direct access to the tables themselves.
No you cannot (to the best of my knowledge) specifically lock a table
to not allow more records directly from the Database Window, or through
some other code.
Make sense?

You can set a Form's AllowAdditions property to "No" to not allow more
records to be added, but if a user can get direct access to the table, then
you cannot stop that.

To truly achieve your goal you would need to do at least all of the following:
1. Completely secure the application using Access User Level Security (ULS).
And it must be done *right.* You must also deny all permissions to the tables
themselves and only use RWOP queries to read/write data.
2. All data entry must be done through forms. Period.
3. You must use code in your forms to limit the number of records allowed
in the table(s).
4. You should create custom menu bars and toolbars to limit what functions
the users have access to.
5. You should disable the Shift key bypass using the correct DDL code
so your users cannot bypass the Startup options.

Not a trivial task for sure, but it can be done.

You may want to read MVP Tony Toews thoughts on this particular
subject as well here:

http://www.granite.ab.ca/access/demo.htm

Hope that helps,
 
Jeff said:
in message:




Yes and No are the correct answers.
Yes you can limit the number of records in a table by using some code and
never allowing users direct access to the tables themselves.
No you cannot (to the best of my knowledge) specifically lock a table
to not allow more records directly from the Database Window, or through
some other code.
Make sense?

You can set a Form's AllowAdditions property to "No" to not allow more
records to be added, but if a user can get direct access to the table, then
you cannot stop that.

To truly achieve your goal you would need to do at least all of the following:
1. Completely secure the application using Access User Level Security (ULS).
And it must be done *right.* You must also deny all permissions to the tables
themselves and only use RWOP queries to read/write data.
2. All data entry must be done through forms. Period.
3. You must use code in your forms to limit the number of records allowed
in the table(s).
4. You should create custom menu bars and toolbars to limit what functions
the users have access to.
5. You should disable the Shift key bypass using the correct DDL code
so your users cannot bypass the Startup options.

Not a trivial task for sure, but it can be done.

You may want to read MVP Tony Toews thoughts on this particular
subject as well here:

http://www.granite.ab.ca/access/demo.htm

Hope that helps,
WoW!! Yeah that helps. Since the user can't get to the tables I'm sure
I'm safe :) Maybe...? How do you lock the users out of the tables? I'm
planning on hiding the Database container and disabling the shift key,
I've already hidden all Menu Bars. Thanks
DS
 
in message:
WoW!! Yeah that helps. Since the user can't get to the tables I'm sure
I'm safe :) Maybe...? How do you lock the users out of the tables? I'm
planning on hiding the Database container and disabling the shift key,
I've already hidden all Menu Bars. Thanks

To do this *right* and truly prevent users from accessing the tables
directly you will need to implement full blown User Level Security
with all the bells and whistles.

Why?

Create a new database and then link to the tables in your current database.
Can you add records to the table(s) this way?
If the answer is "Yes", then what is to stop your users from doing the
same thing?

That is why ULS is needed to prevent users from directly accessing
the data tables. ULS can be used to assign permissions to data objects.
If you have never used ULS before be prepared for some seriously
long studying on the subject. It can be a challenging subject and you
will not get this in an hour; probably not even in a day either. You
should review all the security links I have accumulated here:

http://www.ltcomputerdesigns.com/JCReferences.html#Security

Make sure you practice on "dummy" databases before experimenting
with your real databases.

Good luck,
 
Back
Top