Error 3112 No read permissions

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have written a VBA routine that allows combining of records containing
duplicate information. It works fine on my PC, and it worked well on a PC on
a client's site until another user logged on and tried to use the program on
a different PC. She got the Error 3112 No read permissions message for the
table containing the records. I then went back to the PC where the routine
had previously worked and got the same message.

This is a relatively new project and I had run the user level security
wizard on the front end so as to be able to track user entry and changes to
records. But, I did not apply the secuirty to the back end. Seems strange
that I am getting this message for a table that is in the unsecured back end.
And, also quirky that it worked and then did not work.
I am using Access 2003 for this project.
Could not find anything in the knowledgebase on this error message.
 
Things usually do not work & then automagically stop working. 9999
times out of 10000, something has changed in between!

Does the message appear the instant that someone logs on, or only when
they execute certain lines of code? If the latter, what are those lines
of code? What is the error message /precisely/?

It sounds suspicious to have code for merging duplicate records. That's
ok as a one-off fix for imported bad data, but not as a permanent part
of your database. If you plan it as a permament part, why are you
letting them create duplicate records in the first place?

HTH,
TC
 
The duplicate records are the result of a conversion of spreadsheet data
where there were multiple instances of the same organization for several
people. The routine allows the user to choose organization records to be
combined and to choose the record they want to keep. It then updates the
organizationID to that of the kept record for all the people involved.

I gave the demo, then rather immediately, one of the observers went to her
PC, was able to log in to the program OK. She got the error message "No read
permissions on tblOrganization" when she tried to combine some records. There
was no more than 15 minutes between the two events, and I made no changes to
the program during that period of time.
 
MamaGrubb said:
The duplicate records are the result of a conversion of spreadsheet data
where there were multiple instances of the same organization for several
people. The routine allows the user to choose organization records to be
combined and to choose the record they want to keep. It then updates the
organizationID to that of the kept record for all the people involved.
Click to expand...

That sounds good.

I gave the demo, then rather immediately, one of the observers went to her
PC, was able to log in to the program OK. She got the error message "No read
permissions on tblOrganization" when she tried to combine some records. There
was no more than 15 minutes between the two events, and I made no changes to
the program during that period of time.
Click to expand...

It's been said that one of the best debugging techniques, is to demo
your code to someone else! (Of course, it instantly chooses that moment
to fall in a heap.)

It sounds to me as if the other person - and now, perhaps you yourself
- are not using the correct workgroup information file.

It's difficult to diagnose such problems by remote control. There are
so many things that could have gone wrong. Here's what I suggest you
try, as a "quick fix" to get it working again.

1. Find all of the workgroup (.mdw) files on your PC;

2. Try them out, one by one, by starting the database (on your PC) via
a shortcut of the following form, until you find a workgroup file that
works:

(all on one line)

"full path to MSACCESS.EXE"
"full path to the database"
/wrkgrp "full path to the workgroup file"

3. Once you've found a workgroup file that works, copy it to the other
user's PCs, and give them a shortcut (as described above) for them to
start their copy of the database, with their copy of that workgroup
file.

Be careful not to overwrite any existing workgroup files or shortcuts
on any PCs. Then, even if the process above does not work, at least you
haven't gone backwards.

HTH,
TC
 
Well, at least the demo went very well. It did not crash until it got into
the user’s hands.

I had set up desktop icons on both PCs with the target reading something
like this:

"C:\Program Files\MicrosoftOffice2003\OFFICE11\MSACCESS.EXE"
"E:\0\Clients\BCC\BCC_Program.mdb" /WRKGRP "E:\0\Clients\BCC\BCCSecurity.mdw"

This example is the one from my own computer – the three locations are
different on their PCs. Through the past 10 years I have set up at least 15
different client Access db systems up in this way using the icon to define
the workgroup they are using. One thing I know I did differently for this one
was to NOT secure the back end.

Another thing that is different from what I have usually done in the past is
to call the front end from the server rather than having it in a directory on
each user’s C drive. What is the current thinking on that one? The systems
guy for another client recently set up an Access db I developed that way for
them and it seems to be working OK there – so thought I would try it here as
it is so much easier to install a new version.

I will go back to the client site first thing Monday morning and will
install an unsecured version of the program to see if that makes a
difference. I will also try relocating the front end on each C drive to see
if that makes a difference.

I believe Access is new for this location -- I have seen no evidence of any
Access in use or of any other work group files or short cuts on their PCs.

Do you have any other ideas?
 
MamaGrubb wrote:

Well, at least the demo went very well. It did not crash until it got into
the user's hands.
Click to expand...

Ban all users!! :-)

Another thing that is different from what I have usually done in the past is
to call the front end from the server rather than having it in a directory on
each user's C drive. What is the current thinking on that one?
Click to expand...

As I understand it, it is ok to have the FE on the server, as long as
each user has their own copy there. That is, as I understand it, it is
still not accepted practice to have a /single copy/ of the FE on the
server.

Do you have any other ideas?
Click to expand...

If you have real problems matching workgroup files & databases, it is
sometimes useful to display, from the database, what workgroup file is
currently in use. Temporarily add this to your startup code:

msgbox dbengine(0).systemdb

HTH,
TC
 
All is well. I installed the unsecured version and that resolved the problem.
So, it is on to the next issue -- whatever that might be . . . :-)

Once the data is cleaned up and most of the bugs have been flatened (ironed
out), I will probably reapply security -- depends a bit on what their related
concerns might be at that point.

Thanks for your help.
jg
 
Back
Top