Only Admin can change db.Props ?

[Arno R]

Hi there,
I just distributed an application in which I (try to) change db.properties depending on
CurrentUser()
For instance I set the property's AllowBypassKey and AllowBuiltinToolbars to False when
CurrentUser() <> "xx"
I just noticed that the property's can only be changed changed by a user belonging to 'Admins'.
I never noticed this before.
I could swear that in other apps (A97) this works fine without the user being an admin...

Also I am struggeling with a weird kind of error or corruption.
When I start an application as mdb there is no problem at all.
BUT the app (developed in A2000), distributed as mde simply doesn't run in an Ofiice XP environment.
This is Access XP without any service pack.
Error message 'says' something like 'vba-project corruption...'
Maybe there is a relation between the two cases ?

Any of this sounds familiar?

TIA
Arno R

[Larry Linson]

MDEs are not cross-version compatible -- they must be run under the version
in which they were generated. MDBs can be run in later versions of the
product, or converted to MDE in that later version.

Larry Linson
Microsoft Access MVP

"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

Hi there,
I just distributed an application in which I (try to) change db.properties depending on CurrentUser()
For instance I set the property's AllowBypassKey and AllowBuiltinToolbars to False when CurrentUser() <> "xx"
I just noticed that the property's can only be changed changed by a user belonging to 'Admins'. I never noticed this before.
I could swear that in other apps (A97) this works fine without the user being an admin...
Also I am struggeling with a weird kind of error or corruption.
When I start an application as mdb there is no problem at all.
BUT the app (developed in A2000), distributed as mde simply doesn't run in an Ofiice XP environment. This is Access XP without any service pack.
Error message 'says' something like 'vba-project corruption...'
Maybe there is a relation between the two cases ?

Any of this sounds familiar?

TIA
Arno R

[TC]

"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

Hi there,
I just distributed an application in which I (try to) change db.properties depending on CurrentUser()
For instance I set the property's AllowBypassKey and AllowBuiltinToolbars to False when CurrentUser() <> "xx"
I just noticed that the property's can only be changed changed by a user belonging to 'Admins'. I never noticed this before.
I could swear that in other apps (A97) this works fine without the user being an admin...

Check out the DDL (4th?) parameter of your CreateProperty calls.

HTH,
TC

Also I am struggeling with a weird kind of error or corruption.
When I start an application as mdb there is no problem at all.
BUT the app (developed in A2000), distributed as mde simply doesn't run in an Ofiice XP environment. This is Access XP without any service pack.
Error message 'says' something like 'vba-project corruption...'
Maybe there is a relation between the two cases ?

Any of this sounds familiar?

TIA
Arno R

[Arno R]

Thanks for the info TC

Check out the DDL (4th?) parameter of your CreateProperty calls.

The help states that the DDL property is False by default.
I didn't change any value I'm sure.

So I decompiled, Created a new mdb etc.
Then I changed the values to create the properties.
Still no go to change the props in code for the 'normal' user.

Again a new db
Now I created the properties in code with the parameter DDL set to FALSE
Still no go to change the props in code for the 'normal' user.
This is bizar !

I gave all users 'admin' rights to the db and it was allright then ...
They still aren't members of the admin-group and can't change anything I don't want them to.

Arno R

[Arno R]

> MDEs are not cross-version compatible -- they must be run under the version

in which they were generated. MDBs can be run in later versions of the
product, or converted to MDE in that later version.

Hi Larry,
Are you sure about this ??
In my experience A2000 MDEs wil run without any problems in A2k2.
One other app works the same way I am sure.
(developed in A2000, and distributed as mde to A2k2 'environment')
AFAIK you just can't create A2000 MDEs from A2000 MDBs running in A2k2.

Arno R

[TC]

Thinking more about this.

If the db props are treated like other objects, then, the users who can
change those props would be:
* the owner of the database, and
* any user granted Administer permission on the database.
* CreateProperty DDL=False would suggests that you do not have to be a
member of the Admins group.

In the database is not secured, and DDL=False, the above list becomes:
* the Admin user, or
* any user granted Administer permission on the database.

So I guess this explains what you've found. If you are *not* Admin, you are
not the owner of the (unsecured) database, and you are not (in your example)
a member of the Admins group. So the only way you can update the props, is
to be givcen Administer permission to the database.

But wait! There is another method. A general user (with no Administer
permission to the database) could be allowed to execute code which called
CreateWorkspace with a "hidden" Admins group username/password. Then, you
could execute priviliged actions (such as changing the database props) via
that worksace - even though the current (human) user does not have
permission to change thos props directly!

Of course, you would have to MDE the database, so a user could not examine
your code, & see the username/password of the hidden Admins group member.

Check up on CreateWorkspace. I think that will be your solution. (Then you
could also change DDL back to true, if you wanted.)

HTH,
TC
"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

Thanks for the info TC

Check out the DDL (4th?) parameter of your CreateProperty calls.
The help states that the DDL property is False by default.
I didn't change any value I'm sure.

So I decompiled, Created a new mdb etc.
Then I changed the values to create the properties.
Still no go to change the props in code for the 'normal' user.

Again a new db
Now I created the properties in code with the parameter DDL set to FALSE
Still no go to change the props in code for the 'normal' user.
This is bizar !

I gave all users 'admin' rights to the db and it was allright then ...
They still aren't members of the admin-group and can't change anything I

don't want them to.
Arno R

[Arno R]

>If the database is not secured, and DDL=False, the above list becomes:

* the Admin user, or
* any user granted Administer permission on the database
So I guess this explains what you've found. If you are *not* Admin, you are
not the owner of the (unsecured) database, and you are not (in your example)
a member of the Admins group. So the only way you can update the props, is
to be givcen Administer permission to the database.
Do you think the database is not secured or am I misreading you?
But wait! There is another method. A general user (with no Administer
permission to the database) could be allowed to execute code which called
CreateWorkspace with a "hidden" Admins group username/password. Then, you
could execute priviliged actions (such as changing the database props) via
that worksace - even though the current (human) user does not have
permission to change thos props directly!

Very interesting, I might try this just to see if it works.
Condition for this is that I can run the app as mde
In my initial post I wrote that I also had a problem with this <sigh> ...

BUT the app (developed in A2000), distributed as mde simply doesn't run in an Ofiice XP

environment.

Next week I'll find out if this is solved. I think I found some corruption in a form.
Used SaveAsText and LoadFromText for a couple of forms.
Yet another problem that I can't explain.
When I deleted db.props through code in a loop I could not start the db again ... @#$%$
Sub TestProps()
Dim i As Integer
On Error Resume Next 'You can't delete build-in props
For i = 0 To CurrentDb.Properties.Count - 1
Debug.Print CurrentDb.Properties(i).Name
CurrentDb.Properties.Delete CurrentDb.Properties(i).Name
Next i
End Sub

Access 'complained' that the db was converted from a previous version by using DAO method
CompactDatabase etc.
(Message in Dutch, translation maybe not 100% )
This MUST be a bug. I created a NEW db in A2000. Just set some properties (menu StartUpOptions)
Then I ran the code. When you close the db, you can't get in again.
Compact and repair won't work.
I think I will start another thread on this.

Thanks a lot for sharing your ideas.

Arno R

[TC]

Arno R <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

If the database is not secured, and DDL=False, the above list becomes:
* the Admin user, or
* any user granted Administer permission on the database
So I guess this explains what you've found. If you are *not* Admin, you are

not the owner of the (unsecured) database, and you are not (in your example) a member of the Admins group. So the only way you can update the props, is to be givcen Administer permission to the database.
Do you think the database is not secured or am I misreading you?

Sorry, I thought you said that it was not secured. But I have lost the start
of this thread, so I'm probably just mistaken.

But wait! There is another method. A general user (with no Administer
permission to the database) could be allowed to execute code which called CreateWorkspace with a "hidden" Admins group username/password. Then, you could execute priviliged actions (such as changing the database props) via that worksace - even though the current (human) user does not have
permission to change thos props directly!

Very interesting, I might try this just to see if it works.
Condition for this is that I can run the app as mde
In my initial post I wrote that I also had a problem with this <sigh> ... BUT the app (developed in A2000), distributed as mde simply doesn't

run in an Ofiice XP environment.
Ok, that's a problem! Maybe you could use access security to deny design
permission to the form module(s) in question? Then the db is not an MDE, but
none-the-less, they will not be able to view the code containing the hidden
username/password. Note: I know that access user-level security no longer
works for standard modules in a2000(?)+, so you might need to check that itdoes< apply to form modules - I don't know.
Next week I'll find out if this is solved. I think I found some corruption in a form. Used SaveAsText and LoadFromText for a couple of forms.
Yet another problem that I can't explain.
When I deleted db.props through code in a loop I could not start the db again ... @#$%$ Sub TestProps()
Dim i As Integer
On Error Resume Next 'You can't delete build-in props
For i = 0 To CurrentDb.Properties.Count - 1
Debug.Print CurrentDb.Properties(i).Name
CurrentDb.Properties.Delete CurrentDb.Properties(i).Name
Next i
End Sub
There are some issues with deleting collection members in a loop of that
form. Also, CurrentDb refreshes all collections. That is an expensive
operation. You really want to call CurrentDb >once<, then cache the
reference.

So maybe try this:

dim db as database
set db = currentdb()
while db.properties.count > 0
on error resume next
db.properties.delete db.properties(1).name ' delete first member.
on error goto 0
wend

Check whether the first collection member index is 1 or 0. I can't remember.

HTH
TC


Access 'complained' that the db was converted from a previous version by using DAO method CompactDatabase etc.
(Message in Dutch, translation maybe not 100% )
This MUST be a bug. I created a NEW db in A2000. Just set some properties (menu StartUpOptions) Then I ran the code. When you close the db, you can't get in again.
Compact and repair won't work.
I think I will start another thread on this.

Thanks a lot for sharing your ideas.

Arno R

[TC]

Er, but as others have said elsewhere, you will probably not want to
continue deleting the database props!

HTH,
TC

[Arno R]

Hi TC

Note: I know that access user-level security no longer
works for standard modules in a2000(?)+, so you might need to check that it

does< apply to form modules - I don't know.

Do you know where I can find more info on this ?
I don't want users to be able to see the code

There are some issues with deleting collection members in a loop of that
form. Also, CurrentDb refreshes all collections. That is an expensive
operation. You really want to call CurrentDb >once<, then cache the
reference.

You are right, thanks

Arno R

[Michael \(michka\) Kaplan [MS]]

"Arno R" <ar****************@tiscali.nl> wrote...

Note: I know that access user-level security no longer
works for standard modules in a2000(?)+, so you might need to check that it

does< apply to form modules - I don't know.

Do you know where I can find more info on this ?

Clearly documented in help that security no longer applies to modules.
I don't want users to be able to see the code

MDE. Thats what it is there for. No other solution exists.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.

[Larry Linson]

Sorry, I misread what you wrote. I thought you were generating the MDE in
Access 2002 and trying to run it in Access 2000. I know that does not work;
I haven't tried the other and haven't seen it discussed.

Larry Linson
Microsoft Access MVP

"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

MDEs are not cross-version compatible -- they must be run under the version in which they were generated. MDBs can be run in later versions of the
product, or converted to MDE in that later version.

Hi Larry,
Are you sure about this ??
In my experience A2000 MDEs wil run without any problems in A2k2.
One other app works the same way I am sure.
(developed in A2000, and distributed as mde to A2k2 'environment')
AFAIK you just can't create A2000 MDEs from A2000 MDBs running in A2k2.

Arno R

[TC]

"Arno R" <ar****************@tiscali.nl> wrote in message
news:3f**********************@dreader2.news.tiscal i.nl...

Hi TC

Note: I know that access user-level security no longer
works for standard modules in a2000(?)+, so you might need to check that it

does< apply to form modules - I don't know.

Do you know where I can find more info on this ?
I don't want users to be able to see the code

The only other way would be the so-called project/VBA?/VBE? password. Check
in online help.

HTH,
TC

There are some issues with deleting collection members in a loop of that
form. Also, CurrentDb refreshes all collections. That is an expensive
operation. You really want to call CurrentDb >once<, then cache the
reference.

You are right, thanks

Arno R