Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

no read permission on msysmodules2

Status
Not open for further replies.

jfrasier

Technical User
Apr 5, 2000
33
US
I have an Access 97 database stored on an NT 4 server with users in various buildings accessing it. All users in most locations have had NO problems whatsoever using this file. However users in 2 locations usually get the message "Record(s) can't be read; no read permissions on msysmodules2". From time to time the message is "disk or network error". One of the locations has never been able to use this database and the other one could for awhile but can't now.

Any ideas?

Jane Frasier
 
I would check with your network administrator. The user that can't use the database correctly, He/she may not have enough user-rights for that particular directory / server. Have the administrator compare the rights of people that can access the database to the ones that can't.
 
I have checked permissions, plus I get the same errors and I have administrator rights on the network and am owner of the database.

But thanks.

Jane
 
I did a search on the internet and came up with this.
No read Permissions on "MsysModules2"

You may get this error message when trying to open a MDE built from a secured database.

Record(s) can't be read; no read permissions on 'MsysModules2'

This problem occurs because only the owner of the MDE file or a member of the Admins group when the MDE file was created can successfully open an MDE file created from a secured database that contains modules.

For more details and a workaround, look at this Knowledge Base article.


Q170696
ACC97: "Can't Read" Error, Trying to Open MDE Containing Module

This is the website address where I found the info:
 
I found that article also. I don't think it pertains because this is not an MDE. I also never "secured" this database with Access and EVERYONE has full control of the file and always has.

Jane
 
Sorry, I'm at the end of my rope. I know you'll find the answer it's just a matter of time.
 
Jane,

Twenty Questions? (Hardware, Software or networking)

Have you checked the path for the 'dis'abled users (herein after refered to as "they")? Is is correct (note - htis does not necessarily mean 'the same').

Are they using the same O.S. (incl. Version)?

Do they have the same version of Ms. Access?

Do they have the same add-ins/options/references ... ?

Are they on a different network node/path?

Are they on a WAN while the 'lucky ones' are on a LAN?

Is this a "split" database, with the data being the problem, but each user having a seperate copy of the front end?

If it is split, is the access to the back end "hard-coded" in the front end? As a "URL" type address or a "network" type address?

Can you (reasonably) get to specific instances (Machines) which can (and cannot) acccess the db to compare the processes used to open the database?

Could you try to "step" through the process which opens the database manually, and see EXACTLY where the error occurs?



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
I do have answers to most of those questions but one thing that I didn't mention before is that I brought one of "their" computers to my building, turned it on and I could access and use the database fine.

This would lead one to question something about the network, right? Router, hub?

Jane

 
Not really. The path and HOW it is accessed is still in the running for 'culprit'. I didn't mean/ecpect detailed responses, just throwing out some of the shards of broken database connections I have bled on. Work through the list, cross off the items which are PROVABLY not the problem. Rember the words of Inspector H. Perot:
Consider all of the possabilities. Eliminate those which CANNOT be true. Whatever is left, no matter how improbable, MUST be the answer.



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
So I decided to split the database into back/front end. I went to the trouble location and tried to copy the front end database to a hard drive. I got this message - "cannot copy... The specified network resource or device is no longer available". Very odd to me.

I did get the original database to open and run on one PC in this location yesterday but I tried it from an almost identical PC and it didn't. These PCs were running Nt 4, have 128MB RAM, Access SR-2. Other PCs in this location have only 32MB RAM and are running Windows 95 4.00.950B. All Access options are the same. The locations where this works have a similar mix of computers.

I tried several paths -- Open Access, browse the network neighborhood to \\server\psdata\psdatabases\jcpl classes.mbd, starting from network neighborhood and clicking on the file; mapping \\server\psdata to x:\ which is what most user's login scripts does.

I call also open and run other databases that are stored in the same folder. I have compacted and repaired this database numerous times.

I am SO frustrated!!

Jane
 
Sorry about the frustration. It (the frustration) happens to all (programmers) - just sooner/more often for some (usually beginners). I often use the explaination that programming is inherently frustrating. After all, the programmer is almost always attempting to something new. If it has already been done - we just copy the old (and sometimes make changes) - otherwise it is by definition "new".

Oh well, on to other issues/topics.

It would appear to obvious that if you get the message that the object is unavailable - then you cannot open/run it! This should provide a smaller arena for researching the problem.

I would think that splitting the database, while 'a good thing' eventually - is just creating additional opportunities for problems & issues while you are wrestling with this particular alligator.

Another "clue" for me is the "mapping". In my experience, this is a BAD approach. I always use URL addressing for multiuser databases. Often, the code internal to the db refers to itself (opening a database object with a path ...). This may also require that the Mapping be changed. This blocks access to Users which have a different path/map.

Can you 'see' the mdb file with 'Explorer' or the NT equivalent? Can you copy it through that mechanisim?

If you can copy it to your local HD, try to run it directly from there. If that 'works', then I would look even more closely at the networking arrangements.

Another effort might be to copy the shortcut from a machine which is able to access the db to your desktop and try using it. Does it behave differently? If so, check the comand line arguments for differences. Not just in path/name/User/Password, but all the way down to individual characters. Copy the commamd line from one what works - and one that dont into VBA strings and do a char by char compare. ALL differences are (may be?) significant. Output the char position, the char from each, the asc(chr) from each and a flag/boolean to see if they are the same char. Especially if you are using mapped drives, you need to BE CAREFUL in accepting variations. Someone mapping the db to "Y" instead of "X" may be the root of the problem.

Try some soloutions. Post the incremental results here. Someone will be able to wend their way to the 'right stuff'



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
When you say "URL addressing" do you mean \\server\folder\filename.mdb, or something else?

Yes, I can see the file in Explorer and that is how I was trying to copy it to the hard drive.

I tried opening the file from Explorer, browsing through the Network Neighborhood, not using a shortcut, and that didn't work.

The shortcuts that work are very simple -- they just show \\server\folder\folder\filename.mdb with no username, password, command line parameters or anything.

I probably can't get away from my office today to go to the "trouble" location and I will be out the rest of the week.

Thanks for all your suggestions. Something is going to click one of these days.

Jane
 
"URL addressing" = \\server\folder\filename.mdb

You can "see" the MDB file in explorer - but you cannot copy it with Explorer. This pretty much means it is a network permissions problem!

Even though you are a network administrator, you appear to NOT have permissions in THAT folder!

Check this again .... and again ... and again. then have someone else check it from somewhere else!



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
OOPs - sorry. To muck=h "Jolt"/excitement. Ignore

You can "see" the MDB file in explorer - but you cannot copy it with Explorer. This pretty much means it is a network permissions problem!

Windows XYZ will not permit the copy of an open file. The only way to do this in Win XYZ is to kick' everybody else off of the system (but only for a few minutes).

Sorry about the mis-direction. To many things in the air right now.





MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
Yes, of course. However yesterday I was trying to copy the newly created frontend database that I am 99.9999% sure no one else was in because it was in a separate folder and no one else knew it was there.

Jane
 
O.K. can you 'see' the .LDB file associated w/ the db (.MDB file - with same "first name")? Try to open that one. It should show the Users who are accessing records in the DB, along w/ their machine ID's (& some other 'stuff' - which is mostly indecipherable).

If your last post is correct, then I think we are back to the network permissions question.

On the other hand, if you are unale to open the db, how could you split it? Also, I did not think you could do a split with multiple users logged on? So, were you able to "kick" everbody off, get (exclusive) rights, open the db, do the split, close 'it', and then NOT be able to open it again?

One more errant thought - is your Ms. Access set up to open dbs in "exclusive" mode while otherts are set up to opne "shared"?

MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
I made of copy of the real database, renamed it and put it in a separate folder, THEN split it.

And no, I do not open exclusive.

Jane
 
Did you keep - or can you get another copy of the real database?

If so, place it (copy of real ...) on your local hard drive. Try to 'run it from there. If sucessful, it point strongly to the network and even to network permissions.

Can you copy each component (front end/back end) of the db to your local HD and re-integrate them. Try the above (run from local HD). Does this work?

Do you log on to the network with seperate logons as Admin and User? If so, then the permissions probable ARE different, so check the different settings.

Since you are an Admin, copy the db folder to another one on the network server where the db resides. Set the permissions for this folder to "public" access read/write/create for ALL . Try to run the db from this place?

Am I giving you to much? If you're tired of my suggestions - feel free to say so.



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over
 
No, your suggestions are great. I am learning a lot. I am sad because I am about out of time to work on this until next week as I will be out of the office. Fortunately the users at the location are coping fine without it (They call someone else to look stuff up).

Thanks so much for your suggestions and I will let you know what I find out.

Jane
 
You can go to tools option advance and pick system objects then tools security user permissions and then you should see the msobjects to give permissions. Microsoft said 97 has this problem frequently. You have to do tools security user permissions click groups hit users then on right pick mssysmodule2 click read,update,insert and delete click apply and OK. They didn't say why it loses this one particular permission. Good luck, it's really easy just a pain because you have to repeat it all the time.
Thanks
Coni
a friend
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top