Question for Graham Seach on his book

  • Thread starter Thread starter Jeff Conrad
  • Start date Start date
J

Jeff Conrad

This question is for Graham, but if anyone else has a copy of his book and/or
wants to jump in feel free.

Graham, a question about your book:
Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html

I'm not even sure if you wrote Chapter 6, but since you frequent these groups
the most more than the other authors I thought I might ask you.

On Page 149 of Chapter 6 there is a table listing the various Permission Constants
and Values for the database objects. I have been studying these and have found a
perplexing issue. From my testing on a 97 database I have found a LOT more
permission values than the ones listed in the table. For example, the table in the
book lists 7 Permission Values, but in my testing I have found no less than 36 object
permission values for tables alone! I'm not really having a problem, this is just curiosity.
Why the difference in numbers? Is it just the Access version?

Thanks for any comments.
 
Oops, slight correction to my post.

This sentence:

"For example, the table in the book lists 7 Permission Values,
but in my testing I have found no less than 36 object
permission values for tables alone!"

Should actually have said:

"For example, the table in the book lists 7 Permission Values for tables,
but in my testing I have found no less than 36 object
permission values for tables alone!"

Sorry.
 
Hi, Jeff.

I don't have the book, but I assume that enumerating through the members of
the DAO.PermissionEnum Class will produce the list you are reading. I see
the following that apply to table permissions:

Const dbSecCreate = 1
Const dbSecDeleteData = 128 (&H80)
Const dbSecInsertData = 32 (&H20)
Const dbSecReadDef = 4
Const dbSecReplaceData = 64 (&H40)
Const dbSecRetrieveData = 20 (&H14)
Const dbSecWriteDef = 65548 (&H1000C)

There are a bunch of other security permissions constants in this class, but
those apply to other objects, such as the database container. The security
permission values assigned to each table are accumulative for various
combinations of permissions. Perhaps these accumulated values are the
values you discovered that were assigned to different tables you tested.

If not, could you please give a listing of the other object permission
values that you found so that we can attempt to sort it out?

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)


Jeff Conrad said:
Oops, slight correction to my post.

This sentence:

"For example, the table in the book lists 7 Permission Values,
but in my testing I have found no less than 36 object
permission values for tables alone!"

Should actually have said:

"For example, the table in the book lists 7 Permission Values for tables,
but in my testing I have found no less than 36 object
permission values for tables alone!"

Sorry.
Click to expand...
 
Hi Gunny,

Comments in-line....
I don't have the book, but I assume that enumerating through the members of
the DAO.PermissionEnum Class will produce the list you are reading. I see
the following that apply to table permissions:

Const dbSecCreate = 1
Const dbSecDeleteData = 128 (&H80)
Const dbSecInsertData = 32 (&H20)
Const dbSecReadDef = 4
Const dbSecReplaceData = 64 (&H40)
Const dbSecRetrieveData = 20 (&H14)
Const dbSecWriteDef = 65548 (&H1000C)
Click to expand...

Yes, these are exactly the ones (and values) listed in the book.
There are a bunch of other security permissions constants in this class, but
those apply to other objects, such as the database container.
Click to expand...

Yep, I understand that.
The security permission values assigned to each table are accumulative for various
combinations of permissions.
Click to expand...

Yes, I was aware of that as well.
Perhaps these accumulated values are the values you discovered that were
assigned to different tables you tested.
Click to expand...

That's what I was thinking as well.
Perhaps the values I am finding are an *accumulation* number???
If not, could you please give a listing of the other object permission
values that you found so that we can attempt to sort it out?
Click to expand...

At the very least I have found the following values for JUST tables:

458245
196101
4
458241
196097
0
523997
261853
65756
458261
196117
20
458325
196181
84
458357
196213
116
458485
196341
244
458421
196277
180
458389
196245
148
1048575
852478
458293
196149
52
524029
2612885
65788
1048319

Interesting huh?
 
Hi Jeff,

I normally don't frequent the security newsgroup, so I didn't know about
your question until Doug Steele emailed me about it.

Yes I did write Chapter 6. The permissions listed in the table on Page 149
reflect the 17 permissions found in the PermissionEnum class. These are the
only permissions that can be applied to any Access object.

The permissions listed in this table, were classified in this way so readers
would have some basis for understanding their purpose. The range of values
you have observed are, as Gunny suggested, accumulated enum values, but not
just from the Tables category. When you include values from the Container
category, you can arrive at a far greater range of values than just using
the values from the Table category.

The real problem with this table, which is typical of many problems
throughout the book, is that the publisher arbitrarily omitted, added, and
rewrote bits without our permission. They even failed to redraw our sketches
and screen caps, despite having promised to do so. A perfect example of the
type of thing they did can be seen on Page 113. The first section heading -
"Direct Access Objects", was "Data Access Objects" when I sent it to them. I
hadn't detected what's occurred to the table on Page 149, but they seem to
have omitted a raft of stuff, perhaps to keep it all on one page. It's
possible that I stuffed up, and since I had a disk crash and lost all my old
chapter versions, I have no way to check, but from memory, this table was
meant to show the values that could be applied to *all* objects. An artifact
of this can be seen by the fact that the last three values refer
specifically to forms (but notice there is now no Form category).

I'm sorry for the confusion, but I hope I've clarified the apparent
discrepancy for you.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
 
Hi Graham, thanks for your time.

Comments in-line...
I normally don't frequent the security newsgroup, so I didn't know about
your question until Doug Steele emailed me about it.
Click to expand...

I figured this would be the best place to reach you.
Thank you Doug for the ping.
Yes I did write Chapter 6. The permissions listed in the table on Page 149
reflect the 17 permissions found in the PermissionEnum class. These are the
only permissions that can be applied to any Access object.
Click to expand...

Yep, that makes perfect sense.
The permissions listed in this table, were classified in this way so readers
would have some basis for understanding their purpose. The range of values
you have observed are, as Gunny suggested, accumulated enum values, but not
just from the Tables category. When you include values from the Container
category, you can arrive at a far greater range of values than just using
the values from the Table category.
Click to expand...

That would seem to make sense with my findings so far.
But just so we are understanding each other, the 37 permission values I listed
in my response to Gunny were only on tables, no other objects. I have found
at least 57 values for saved Query objects. And there is some overlap of values.
So you are saying the values I am finding above the Permission Constants listed are
accumulated values that somehow are being included with the Container's category?
The real problem with this table, which is typical of many problems
throughout the book, is that the publisher arbitrarily omitted, added, and
rewrote bits without our permission. They even failed to redraw our sketches
and screen caps, despite having promised to do so. A perfect example of the
type of thing they did can be seen on Page 113. The first section heading -
"Direct Access Objects", was "Data Access Objects" when I sent it to them.
Click to expand...

You know I actually did find that odd!
I just passed over it as something strange and did not give it any more thought.
I hadn't detected what's occurred to the table on Page 149, but they seem to
have omitted a raft of stuff, perhaps to keep it all on one page. It's
possible that I stuffed up, and since I had a disk crash and lost all my old
chapter versions, I have no way to check, but from memory, this table was
meant to show the values that could be applied to *all* objects. An artifact
of this can be seen by the fact that the last three values refer
specifically to forms (but notice there is now no Form category).
Click to expand...

I did notice that one for sure! I assumed a heading was not put in by mistake.
I'm sorry for the confusion, but I hope I've clarified the apparent
discrepancy for you.
Click to expand...

No problem at all. I hope my question did not come across the wrong way.
It was not my intention to highlight any discrepancies, I was just curious
about these values. I began testing the values by changing the permissions
in the Security dialog box and seeing what resulted. I was a little surprised
to see a bunch of other values! Naturally curiosity got the best of me so
I kept digging.

Thanks for your time.
 
Hi, Graham.

Thanks for the clarification.

Is there a list somewhere of the undocumented (by Microsoft) values that are
added to tables in addition to the Container and Document values? As you
know, sometimes the values for a table's "AllPermissions" Property don't
exactly match the summed values of the applicable constants in the
DAO.PermissionEnum Class.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
Jeff,

With regard to the range of values you've observed for the Table object,
what I meant to say was that you can use the enum values for the Containers
object on the Table object. For example:

dbSecDelete + dbSecDeleteData

With regard to the book itself, I've justresigned myself to it. ;-7

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia

Microsoft Access 2003 VBA Programmer's Reference
http://www.wiley.com/WileyCDA/WileyTitle/productCd-0764559036.html
 
Hi, Graham.
All the allowable values are given in the
PermissionEnum class.
Click to expand...

The numbers don't always add up.

For example, a user has all of the security permissions available on a table
and the "AllPermissions" Property on that table is 1048319.

From the table permissions:

dbSecCreate = 1
dbSecDeleteData = 128
dbSecInsertData = 32
dbSecReadDef = 4
dbSecReplaceData = 64
dbSecRetrieveData = 20
dbSecWriteDef = 65548
------------------------------------
Subtotal: 65797

From the Tables Container permissions:

dbSecReadSec = 131072
dbSecWriteOwner = 524288
dbSecWriteSec = 262144
------------------------------------
Subtotal: 917504

From the Database permissions:

dbSecDBAdmin = 8
dbSecDBCreate = 1
dbSecDBExclusive = 4
dbSecDBOpen = 2

------------------------------------
Subtotal: 15

Added together:

Subtotal: 65797
Subtotal: 917504
Subtotal: 15
------------------------------------
Total: 983316

This total is a bit short of the value reported for the "AllPermissions"
Property:

1048319
- 983316
------------------------------------
65003

If this value must be derived only from the available constants, then look
at the three constants we haven't used yet:

dbSecDelete = 65536
dbSecFullAccess = 1048575
dbSecNoAccess = 0

No accumulative combination of these three values is equivalent to 65003,
the balance of 1048319 -- the value of the table's "AllPermissions"
Property. dbSecDelete and dbSecFullAccess are both too large to make up
this balance.

So it appears that there are enough constants to total 983316, but not the
reported "AllPermissions" Property value of 1048319 for this table -- unless
there's some undocumented constants that are part of this number.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
Gunny,

If you logically accumulate all the permissions that can apply to the object
(in this case, the Table object), except dbSecFullAccess, you end up with
983293.

dbSecCreate OR
dbSecDelete OR
dbSecDeleteData OR
dbSecInsertData OR
dbSecReadDef OR
dbSecReadSec OR
dbSecReplaceData OR
dbSecRetrieveData OR
dbSecWriteDef OR
dbSecWriteSec OR
dbSecWriteOwner

If you just use dbSecFullAccess only, you get 1048575. I don't know why
there's an apparent difference between the two values, which one would think
indicate the same level of permissions.

You have to remember too, that there can be a difference between the
Permissions property and the AllPermissions property, because the
AllPermissions property includes the permissions the user inherits from
their group membership; it doesn't just reflect the permissions explicitly
assigned to *that* user (that's what the Permission property is for). So
theoretically, if a user is assigned dbSecFullAccess, and one of the groups
to which he belongs has one or more permissions explicitly denied, then it
is possible for the accumulated value in AllPermissions to be less than
1048575. The reverse is true also.

The value of 65003 can be comprised from the extended list shown above.

Regards,
Graham R Seach
Microsoft Access MVP
Sydney, Australia
---------------------------
 
Graham and Gunny,

Thanks for the additional information. I have definitely been learning a
lot from this discussion. I now can see how the different objects and
containers can arrive at different values by the interaction of the various entities.
This is making a lot more sense now.

I first discovered the initial values listed in the book, but after playing with
different options I arrived at different numbers. It became even muddier
when I began to look at the various Groups and users. The Admins group,
Users group, Admin user, and my SuperUser gave me even more variations.
Now normally some of the above entities should have zero permissions but
it was surprising to see my list of new permission values growing by adjusting
their permissions. Verrrrry interesting!

Thanks again for the help!
 
Hi, Graham.

Thanks for the clarification. I had experimented with bitmask operations on
the values assigned to each Permission property, and while I usually came up
with matching numbers for the AllPermissions property, I didn't always do
so, so I suspected either I was taking the wrong approach or there was
something else entering into the equation that I wasn't accounting for. I
figured I should ask, because I've taken the wrong approach often enough
(which may be why I know so many wrong ways to accomplish tasks in Access).
;-)

Inheriting permissions from group membership would explain the gaps I
occasionally saw when just focusing on the bitmask operations on individual
permissions and comparing that value with the AllPermissions property.

Thanks again for the info.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
 
Back
Top