Serious Problem has developed

[Misty]

Somehow, every db on my PC and Lan now will not allow me to use the "New" option for tables or queries. Even when I enter in the "Exclusive" mode.

What in the world can cause this?

To make changes, I had to create a new db and import everything from the db I was making changes to. That worked, but I also had to set all of the options that were set in the old db. What a hassle.

Here's what is freaking me out. I have over 600 db's that I'm responsible for. I didn't check them all, but the first random 10 or so were all the same.

Needless to say, I don't have the time for this!

I think I'll just commit myself...

 

[FLabrecque]

Possible problems:
1. The DB is now in read-only (less likely).
2. Your network rights changed (more likely). You can not create stuff in this directory.

 

[Misty]

I've opened more than 10 of the db's in the exclusive mode and still have the same problem. The db's are in many different directorys on my LAN and also on my hard drive. None of them work properly.

I'm freakin!!!!!!!!!

Could my IT department have caused this somehow?

 

[The_Doc_Man]

I slightly disagree with FLabrecque.

If you have spot-tested 10 or so such DBs and they are ALL unable to open a new table, it isn't that the DB has become read-only. TOO MANY DBs have become R-O for this to be a coincidence.

If you can create a new copy of the DB and it works IN THE CORRECT DIRECTORY, then it is not a network rights/permissions issue, either.

I would do the following, not necessarily in this order:

1. Rejoin the correct workgroup manually for a DB exhibiting this problem. Then try again. If the shortcut icon to the DB specifies a workgroup as part of the "command line", manually join that workgroup and open the db through browsing rather than through the shortcut.

2. Re-install Office. I believe there is a "refresh" option that allows it to find things that are missing that should not be.

3. Try to open one of the misbehaving DBs to look at the User and Group Permissions (from Tools). Look at the database object. See who owns it. (If you can.) If you SHOULD be the owner but you are not, find the person who is now the owner and slap the crap out of him/her. Jump all over that person's stuff. Do the "angry chimp on the desktop" routine. Offer to remove his/her toenails through the nose, thereby avoiding ugly scars.

4. Ask your domain admin if they did anything that would have somehow changed your network ID or your Windows domain-wide SystemID (SID). Or your Group ID (GID). If the SID or a GID has changed, that COULD do it, but I'm not betting on this one. It is unlikely.

5. Look for dangling .LDB files. If no one is in the particular DB, delete the .LDB files and try again.

6. Check your computer for free disk space on the volume that contains your swap file. If possible, defrag the volume and free up at least enough space to hold twice your physical memory size.

7. Run a very thorough virus scan on your system. If you have the option to "check ALL files" (as opposed to "check EXECUTABLE files"), use it.

If none of these ideas gets you anywhere, you need to investigate further to find out more symptoms and post them.

 

[FLabrecque]

Check with them concerning the rights. What do you have to lose?

Check with them. If the IT-staff can open and create new forms with their account, this should proove it's your account at fault. Otherwise, it's another ball game.

 

[Misty]

Thanks for the ideas. I'll try them one at a time and see what happens. You can guess what the potential for mayhem is on this.

I'll drop a note when things are fixed and let you all know what the problem was.

M.