access database, no permissions, no owner

[nlm9802]

Hello,

My apologies if this is the wrong forum, please direct me to a better one if there is

I am assisting one of my customers with their Access (2000) Database. When it is opened, error received is "You don't have permission to run *" To run this object, you must have Open/Run permission for it.

When I look at tools, security, user and group permissions, there is only 1 user (admin) and 1 ground (admins). admin is a member of admins, however under permissions (for the user and for the group) nothing is checked for any object name. So effectively, no permission are assigned. When I try to assign permissions it states that I must have administer permissions to assign these permissions....
If I had administer permissions this wouldn't be a problem, because I wouldn't need to add administer permissions.

This database did work until an unspecified time in the recent past (up to 1 month). backups were of course not kept, and it was saved on a PC, not a server where it would be backed up. I am able to add a user or group to the list, but cannot assign any permissions. Also the owner is not set to any portion of the database. When I attempt to set owner.. you guessed it, I need administer permissions.

I appreciate any help

 

[FancyPrairie]

Who is listed as the owner of the database? Are you pointing to the correct workgroup file? Have you tried creating a new database and importing all of the objects from the current database?

 

[nlm9802]

there is no owner, it says not set or something similar to that.
When I tried to import all of the objects into a new database it said I need read data or read design access for every object in the database.
When I checked ownership on the new database it was set correctly.. the admin user and admins group both had full access (all boxes checked) and admin was the owner of the database. I believe something happenned to remove the administrative/owner settings, but have no idea what it was.
The issue is only affecting this one database.

 

[FancyPrairie]

Are you pointing to the correct workgroup file? Can you export the objects to the new database?

 

[MichaelRed]

Sounds like one of those 'time bombs' set to disable (and frustrate) those left behind by the original programmer. Since you could (if you had permissions set appropiatly) run a procedure and remove all object permissions from all users (including whomever had "admin" permissions) it would appear to be an effective way to disable the individual "App". In particular, I think I would search ALL the apps touched by this individual, checking the code for any (all) possible approaches to the setting of users and groups permissions.

Assuming the original designer/programmer of the app left on other than forced ejection, you might attempt to contact them and inquire about the 'oddity.

If the above doesn't work, AND there is some evidence of malicious activity, legal alternatives might need to be considered, particularly if the app is critical to the org.



MichaelRed

 

[nlm9802]

not sure what a workgroup file is. there is the original database file on the d:\ drive, and the new database i created to try and import the objects in d:\new folder.

I don't *think* it was intentional, as the creator of this database is still there and was the one who asked for assistance. this may be a "power user" issue, where they know enough to cause trouble, but not enough to fix it.

 

[FancyPrairie]

A workgroup file is the file that contains all of the security info. If you launch your db via a shortcut, then the shortcut should have a /wrkgrp switch. If not, then you are using the default system.mdw file. If that's true, then change the name of the current system.mdw to system_old.mdw. Then find another copy of system.mdw (i.e. off the installation disk) and copy the new version to the user's machine. See if that works

 

[MichaelRed]

Any "power User" sufficiently vested in the arcania of Ms. A. Security is (probably) NOT a user at all. This are is supposedly one of the more difficult (and certainly least documented) areas or the overall object model. Given that it 'appears' to be an unsecured db (only admin in admins), I suspect that FancyPrairie has hte better soloution. Just replace the (default) System.MDW with a new copy, making sure that it is in the 'correct' location (or at least the shortcut points to it).





MichaelRed

 

[nlm9802]

sorry for the delay.

It did not make any difference. I replaced system.mdw with one from the install cd, but the database still has no permissions set or settable.

The existing system.mda has some strange entries if it is opened, pointing to various files and referencing a couple different usernames in an "AccessPreferences" table.


any new database has the proper admin permissions/owner.
also the ntfs permissions are set correctly, I was able to take ownership there, but it did not affect the database permissions.

 

[MichaelRed]

"Spend your time and energy with ADO.NET"

Sounds like a suspect. Understanding this may be a key to resolving the riddle. If the code isn't to large, post the relevant snippets.




MichaelRed