User permissions not working

[DesertBoy85]

Here's a weird one. I have a client who has a workgroup file on a shared drive on an office computer other than his own, and the back-end db is on that computer as well. He came in on a Saturday and opened up the front-end, which is on his computer. Unfortunately, the computer with the shared drive was off (both XP machines, btw) and he couldn't get in, obviously. Since he couldn't see the workgroup file or the back-end, he was automatically redirected to the default workgroup file on his hard drive.

The problem is that now he can't run the app from his computer even with the other computer on. If he attempts to open the app, he gets the infamous 'Record(s) cannot be read; no read permission on 'switchboard items'.' message. FYI, he is an admin for both the front and back-end db's.

By itself, that would be fixable. But if he attempts to join the correct workgroup with the mdw on the network, which is on the shared computer drive, he gets the same message the moment he clicks the Join button. Whatever we try he cannot join that workgroup from his computer.

He can go to other workstations in the office and run the app using his name and password, so I know he's still in the workgroup and the permissions are set correctly. It's like XP won't let him join that workgroup, and I'm not sure if it's because of his local machine or due to his network logon. It must be something with the machine, XP, or the MS Office install, because another user on the same machine with a different logon has the same problem. He still has access to everything on that shared drive and can open other docs and files, so I don't think his permissions have been restricted from a Windows security standpoint.

Has anybody heard of something like this before? Any and all thoughts would be appreciated.

--Randy

 

[psemianonymous]

Work from two angles:

1. Attempting to "join" the workgroup fails. Use the Workgroup Administrator to "join" the workgroup permanently (though I don't recommend that in general, it seems like it's already set up that way).

2. Network folder permissions are not allowing him read AND write access to the folder. See if you can create a new file in that directory. If not, work that angle.


It's still very likely #1. I don't know why you can't "join" the workgroup permanently.

(3. ?) As a workaround, create a new shortcut that opens the db with your specific workgroup. Basically you set the target to:

"C:\FULL\PATH\MSACCESS.EXE" "\\NETWORK_SHARE\FULLPATH\DB.mdb" /WRKGRP "\\NET_SHARE\etc\etc.mdw"

 

[RickSpr]

Two possibilities occur to me.
(1) Your administrator is selecting the MDB file, not the MDW file, when attempting to rejoin the workgroup.
(2) Somebody has opened the workgroup file and set up Access security on it.

I wouldn't normally suspect (1), but you said he's getting the "same message", and the message you gave says he doesn't have permission to use the switchboard items table. No way should there be such a table in a workgroup file.

For (2), remove security from the workgroup file. You need to open it directly in Access, using a logon that has administrative permissions. Then reassign full permissions to the Admins group and the Users user.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[DesertBoy85]

Thanks for the ideas, guys. I'll check into these and post back when it's (hopefully) resolved.

BTW, these guys use only the workgroup file on the shared drive since this is the only MS Access app they use. Each workstation has joined that workgroup through the workgroup administrator. I don't think it really matters in this case, but thought I'd clear up something I didn't really explain in the original post.

--Randy

 

[LambertH]

The WMD file may be corrupted. To check that get everyone out ofthe database and then fire up access.

On the file menu select "Open" and the navigate to where the MDW file is located. Select "Workgroup Files" from the file type comobo in the file open dialog and open the MDW file.

You may get a message there and then saying it needs to be repaird, but even if you do not, select Tools / Database Utilities / Repair Database and that should fix things up.


MDW files are really just MDB files in disguise!