Arno R <arracomn_o_s_p_a_m@tiscali.nl> wrote in message
news:3fa39fbd$0$79343$5fc3050@dreader2.news.tiscal i.nl...
[color=blue][color=green]
> >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[/color][/color]
are[color=blue][color=green]
> > not the owner of the (unsecured) database, and you are not (in your[/color][/color]
example)[color=blue][color=green]
> > a member of the Admins group. So the only way you can update the props,[/color][/color]
is[color=blue][color=green]
> > to be givcen Administer permission to the database.[/color]
>
> Do you think the database is not secured or am I misreading you?[/color]
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.
[color=blue][color=green]
> > But wait! There is another method. A general user (with no Administer
> > permission to the database) could be allowed to execute code which[/color][/color]
called[color=blue][color=green]
> > CreateWorkspace with a "hidden" Admins group username/password. Then,[/color][/color]
you[color=blue][color=green]
> > could execute priviliged actions (such as changing the database props)[/color][/color]
via[color=blue][color=green]
> > that worksace - even though the current (human) user does not have
> > permission to change thos props directly![/color]
>
> 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> ...[color=green][color=darkred]
> >>> BUT the app (developed in A2000), distributed as mde simply doesn't[/color][/color][/color]
run in an Ofiice XP[color=blue]
> environment.[/color]
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 it[color=blue]
>does< apply to form modules - I don't know.[/color]
[color=blue]
> Next week I'll find out if this is solved. I think I found some corruption[/color]
in a form.[color=blue]
> Used SaveAsText and LoadFromText for a couple of forms.[/color]
[color=blue]
> Yet another problem that I can't explain.
> When I deleted db.props through code in a loop I could not start the db[/color]
again ... @#$%$[color=blue]
> 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[/color]
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
[color=blue]
>
> Access 'complained' that the db was converted from a previous version by[/color]
using DAO method[color=blue]
> 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[/color]
(menu StartUpOptions)[color=blue]
> 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[/color]
