User-created tables are being made as hidden - Unable to delete/amend as Admin

Question

We have an Access 2003 Database (barbaric, I know) that requires users to create their own unique table, and use that table within a query to pull specified data. After which, the table is deleted and made afresh the next time they run the query...

It seems a very small handful (5 users out of 600+) have seemed to make tables that appear almost like system objects, hidden. I had to go through the options and view hidden/system files for them to appear, as at first I couldn't understand why they would get the error to make a new table when the old table wasn't appearing. Due to this those users are no longer able to delete/amend their existing table to run the queries. When they try, they get the below message:

"Run-time error '3033': You do not have the necessary permissions to use the 'TABLE_NAME' object. Have your system administrator or the person who created this object establish the appropriate permissions for you."

I've gone into the tables myself and I'm unable to delete these tables or even find a way to gain access permission to delete them.

I have two questions really:-

Firstly, I don't understand how very occasionally these users managed to make their table in this format (as they have made hundreds in the past normally, and just this one time it seems to have been done in this way). I worry that even by removing these stuck tables that the issue will come around again and we'll have to spend time manually going in and changing permissions to delete these tables.

And second, how would I go around finding a way to delete these tables?

Answer 1

In an MDB format database without ULS (user-level security), user operations are performed as the Admin Access security account user.

In your situation, it seems you have a user --- let's call him Fred --- who created a table named tblFred. But now you are unable to delete that table.

Even though you have not applied ULS, Access still maintains user and group permissions for database objects. And it sounds like somehow the AdMin user has lost the necessary permissions on tblFred.

In order to delete the table, Admin needs DROP permission for tblFred. And if the table contains any data, Admin also needs DELETE permission.

Go to the Immediate window (Ctrl+g) and GRANT Admin those permissions.

CurrentProject.Connection.Execute "GRANT DROP ON TABLE tblFred TO Admin;"
CurrentProject.Connection.Execute "GRANT DELETE ON TABLE tblFred TO Admin;"

I'm unsure about precedence for those statements, so repeat them in reverse order if the first attempt doesn't allow you to then delete the table. And hopefully that effort restores your ability to delete the table using your normal method.

You may want to inspect permissions on other database objects to look for inconsistencies. (And actually you could use this instead of executing the GRANT statements if you prefer.)

DoCmd.RunCommand acCmdUserAndGroupPermissions

However, even if those suggestions worked, I can't explain why the permissions got broken in the first place. As only a guess, I'll blame the fact that you have multiple users sharing the same front-end db file. Although your data is housed in a separate db file, Access still maintains state for operations in the front-end sessions. So when multiple users have the front-end open, things can get confused, and odd things can happen. That is why the safest practice is to give each user their own copy of the front-end db file.

I just read the question and comments again. I had assumed you're using a split application, but you didn't actually say that. If the users are sharing a single db file which contains the data and the front-end pieces (queries, forms, reports, etc.), the situation is more fragile than I assumed. Bad things are bound to happen.