Permissions Keep Changing

[TC]

Janet, I have a way forward which will quickly tell us what is going
on.

That is in a seperate reply. This reply is some general information for
you to consider in due course. //Do not change anything, yet, in
response to these comments!//

YES, I have a back with data and a front with forms, queries, etc.
Ok.

There is one BE and one FE, both stored on a network drive.

See below.

NO. There is one FE on a network drive that all users have access to. I have to
upgrade the db at least weekly, so it would be impossible to go around and upgrade
each person's desktop version since there are about 80 different persons who could
be using this database (though usually only about 10 people are in it

at one time).

Having a single FE is generally thought to increase the chances of
database corruption. It is true that having an FE per user gives rise
to an administrative problem, but there are various ways of handling
that. For example, there are "auto updater" modules that cause the FE
to automatically update itself, from a new version on the server,
whenever required. I recommend that you address this issue in due
course - but //not yet//, since it is unlikely to be the cause of your
current problem. So, //do not// change this yet.

YES a single workgroup file stored on a central server.
Ok.

NO -- Each user simply has a shortcut icon on their desktop, from
right-clicking the front-end file, and choosing "Send to Desktop as
Shortcut."

Mmmm. If you double-click the FE - or a simple shortcut to the FE -
this will use whatever workgroup file was last joined-to, on that PC.
By default - when Access is first installed, that file will be, the
default workgroup file on that PC. So, if the database is actually
opening (as it clearly is), one of two things must be true:

(a) You have used the workgroup administrator, on each PC, to join each
PC to the correct workgroup file on the server; or,

(b) The database will open with the PC's normal (default) workgroup
file. (This is common, & means that the database has not been properly
secured.)

I assume it is (a) - correct? If so, that is not the normal way to do
it, because that will cause the server's workgroup file to be used for
/every/ database on the PC - even ones that aren't secured. Those
local, unsecured databases should normally use the PC's initial,
default workgroup file.

Usually, you would use the shortcut described in 5, to open a secured
database. The shortcut uses the /wrkgrp switch to select the server
workgroup file /for that run only/. Then, you can leave each PC joined
to its normal (default) workgroup file, for running other (unsecured)
databases.

//Do not change this yet.// Leave it as it is, until we work out what
is causing your problem.

6. Do any users start the system by double-clicking a database file

Probably so - thinking about my answer to #5 above -- but it's a short-cut
to the file, not the file itself. Does that matter?

See 5. //Do not change this yet.//

I do, and the IT Director could if she wanted (though she says she doesn't).
I have the FE setup to that the tools menu is not in the Startup options so
regular users can't click Tools, Security, Workgroup Administrator, and I
have the shift+enter key disabled, so they can't get to it that way.
Is this what you mean?

Mmmm. Do you mean that you used the workgroup administrator program
/once/, on each PC, to join that PC to the workgroup file on the
server? Or do you use it repeatedly? If so, why?

I open the db, go to tools/security/permissions and look at each group
and what permissions are set for what tables/forms/queries/macros,

etc.

I've addressed this in my other reply.

During the interim (this past weekend) the "User Group" permissions were
changed again on both front end and back ends to include ALL permissions for
MSysAccessObjects system table. (snip)

You'll get nowhere looking at system table permissions. The underlying
database engine (MS Jet) has certain requirements of the system tables.
It will re-apply those requirements, automagically, in certain cases,
if you try to change them. //Do not// fiddle with the system tables!
That will only lead to grief & confusion.

Cheers,
TC

 

[TC]

Janet, further to this, I ask you not to make //any// changes to your
system, except for those that I ask you to make, as part of the process
of solving your problem.

Otherwise, it is just too difficult to stay on a single track.

That is my requirement, for my committment to solve your problem.

Cheers,
TC
(off for the day)

 

[Joan Wild]

You'll get nowhere looking at system table permissions. The underlying
database engine (MS Jet) has certain requirements of the system tables.
It will re-apply those requirements, automagically, in certain cases,
if you try to change them. //Do not// fiddle with the system tables!

TC, that is the main point that I think you are missing. The only table
that Janet has reported the permissions keep changing on is a system table.

 

[Guest]

That is the most obvious table they are changing in. I have seen them change
in other tables, as well. I'm going to check, again, today to see if
permissions in the other tables have been changed. My biggest concern was
the system table because it seemed to change everything to FULL permissions
-- but there have also been changes in other tables, as well. I'll let you
know what I find.

 

[Guest]

TC: Thanks so much for all your help. I'll try to answer your questions
below within your text:

Janet, I have a way forward which will quickly tell us what is going
on.

First, I've made some general comments in a //seperate reply//. Those
comments are just for information at this stage. //Do not change
anything after reading those comments!//
OK.

Second, when you say that you open the db & the permissions have
changed:
- which db are you opening - the BE, or one of the FEs?
- exactly how do you open it?

They changed on both BE and FE. I open each database by clicking the FE or
BE mdb file.

Third, here is how to proceed right now.

1. Pick a table whose permissions are automagically changing. Make sure
it is a BE table, not an FE link to a table. Do not use a system table
- use one of your own tables.

Actually, they were having changes in many of the tables, but I will find
one that has changed, and concentrate on that one for the sake of this.
Oddly enough, when I checked today, none of them have changed since I reset
them on Friday (except for the MSysAccessObjects table which the Users group
has full permissions -- and I left it as is for now). After I had noticed
the most recent changes in the BE (last week), though, I attempted to add
more security to the BE by 1) unchecking everything in the Startup Menu
(except for a form that says: "Access Denied!!") and 2) I disabled the
shift+enter key on BE. Maybe this has worked -- especially if, as you say,
the system tends to reset the permissions for system tables to the Users
group, anyway.

2. Put all the permissions (on all your objects) back the way you want
them to be.

They hadn't changed (yeah!) I haven't run the code below yet since nothing
had changed. Should I do it still?

3. Immediately run the code below. NOTE: replace xxxxx with the name of
the table that you chose in step 1. To run the code:

- open the BE db;
- type Ctrl-g to go to the debug window;
- cut & paste the first command;
- put the cursor anywhere in that command;
- press Enter to run that command;
- note the output of that command, then
- repeat for the other commands.

Commands:

debug.print dbengine.systemdb
debug.print dbengine(0)(0).name
debug.print currentuser()
debug.print dbengine(0)(0).tabledefs![xxxxx].owner
debug.print hex$(dbengine(0)(0).tabledefs![xxxxx].allpermissions)

4. Close the db, let your users continue work, and wait for the
permissions to automagically change themselves.

5. Immediately repeat step 3, then

6. Post the output from steps 3. and 5.

Cheers,
TC

 

[Joan Wild]

They hadn't changed (yeah!) I haven't run the code below yet since
nothing
had changed. Should I do it still?

Yes. Since TC seems to get online only once a day, you'll just delay
things. Go ahead and run the code. If/when you see a change on one of the
*non-system* tables, run it again as he asked.

 

[Guest]

OK -- I ran the codes and here's what I got for steps 3 thru 5:

1. it showed the correct location of the MDW file.
2. it showed the correct location of the BE file.
3. it showed my database username.
4. it gave an error message (regardless of which table name I typed in place
of the xxxx): "Compile error. Method or data member not found."
5. it gave an error message (regardless of which table name I typed in place
of the xxxx): "Compile error. Method or data member not found."

Was it supposed to show an error message for #4 and #5?

 

[Paul Overway]

the xxxxxx should be in quotes

 

[Joan Wild]

1. it showed the correct location of the MDW file.
2. it showed the correct location of the BE file.
3. it showed my database username.
4. it gave an error message (regardless of which table name I typed in
place
of the xxxx): "Compile error. Method or data member not found."
5. it gave an error message (regardless of which table name I typed in
place
of the xxxx): "Compile error. Method or data member not found."

debug.print dbengine(0)(0).Containers("tables").documents("xxxx").owner
debug.print
hex$(dbengine(0)(0).containers("tables").documents("xxxx").allpermissions)

 

[Paul Overway]

Actually....I take that back.... but try this instead...

debug.print dbengine(0)(0).tabledefs("SomeTable").Owner
debug.print hex$(dbengine(0)(0).tabledefs("SomeTable").AllPermissions)

 

[Paul Overway]

Good catch! )

 

[Guest]

I tried the code you have below, but got the same error message. I must be
doing something wrong.... I have to go home now and will be back here
tomorrow.

 

[Guest]

I'm not sure what to enter in this code? Put the table name where you have
"Tables" and "xxxxx" ???

 

[Paul Overway]

Just replace the xxxx with the name of a table....leave the rest the same

 

[TC]

Yes, thanks for that. Unfortunately I do not have Access on the pc that
I use to post to the web, so I have to do all code from memory!

Cheers,
TC

 

[TC]

Janet wrote:

(snip)

After I had noticed
the most recent changes in the BE (last week), though, I attempted to add
more security to the BE by 1) unchecking everything in the Startup Menu
(except for a form that says: "Access Denied!!") and 2) I disabled the
shift+enter key on BE.

Janet, I truly can't help you, if you keep making changes. I made that
very clear in my previous posts.

Debugging requires a disciplined, step-by-step approach. If you want me
to help you, you must accept my approach - which in this case means,
//no more changes// unless we have discussed them //first//.

Do you agree to that approach?

TC

 

[TC]

blah![xxx] and blah("xxx") are normally equivalent in those contexts


Cheers,
TC

 

[TC]

Gak!!! I did miss that! But her reply suggests that other tables are
changing as well.

As you, I, & everyone else has said, there is no point messing with the
system tables, or trying to divine what their permissions mean.

Cheers,
TC

 

[TC]

Correct. When we compare the two runs, I expect that we will see a
difference in what database, workgroup file, user, or object, she is
using to compare permissions.

Cheers,
TC

 

[TC]

Janet, further to this, you need to show the actual result of each
command.

TC