MS Access data conversion - Re: Permission probs w/Split database for Access97 & Access2003 Mu

Author

Re: Permission probs w/Split database for Access97 & Access2003 Mu

tiskal

2005-11-08, 4:15 pm

Thanks for the feedback David. I presently have Administer rights for the
database and all its objects and actually am the owner of all the subject
database objects.

Would it help if I create a different workgroup to set up these "new" test
BE & FE databases instead of using the same workgroup that I'm using for my
existing A97 on-line, multi-user, multi-facility database? When I try using
the A2003 software's "Convert database" command and pick my A97FE for
conversion, I get a message telling me I don't have the rights to do so. As I
mentioned I got around this by creating the A2003FE version of the database
by importing all objects. Do these facts shed any more light on the problems
I'm encountering?

Thanks again for your assistance!

--
Tim

" david@epsomdotcomdot
au" wrote:

> Access has two different kinds of Administrator.
>
> 1) Administer Security (member of the admins group used to create the
> database)
>
> 2) Administer Database objects (has admin permission on the object).
>
> You should probably re-create the A2000 FE, making sure again
> that you know which Workgroup File is in use, and which User
> is the owner of the new objects.
>
> microsoft.public.security is a good place to ask this kind of question.
>
> (david)
>
> "tiskal" <tiskal@discussions.microsoft.com> wrote in message
> news:59B40BD5-02DC-4A8A-BD61- 7AFCBE67F240@microso
ft.com...
> front
> as
> in
> with
> the
> on
>
>
>

david epsom dot com dot au

2005-11-08, 4:15 pm

When you imported all the objects to a new database,
you said that anyone who was a member of the A2003
Admins Group could control security, (including Admin,
the default user, who by default is a member of the
default Admins Group)

You now need to secure the new database. To do
so you will need to import all of the objects into
a secured database, while logged in to a secure
workgroup as a secure user.

Forget about having Administer rights for the
database. That is not relevant. Forget about it:
it is not relevant. The Administer rights for
the database are not relevant.

What is important is the Admins Group of the security
workgroup used to create the database.

The Admins Group of the security workgroup used
to create the database is not something you can
easily check or look at. It is not shown in the
security settings. The only way to be sure about
the Admins Group used to create a database is to
plan carefully, act methodically, and record
everything you do.

Normally, you might plan to use the same workgroup
for the A97 and the A2000 database. You would have
to join the A97 workgroup to do that.

Another common idea is to use a completely
different workgroup for database creation,
so that your distribution workgroup does not
contain the Admins Group used to create the
database. To do that you have to record how
you create any security groups, so that you
can create the security groups in both databases.

microsoft.public.security is a good place to ask this kind of question.

(david)

"tiskal" <tiskal@discussions.microsoft.com> wrote in message
news:B7EB8CD3-DDCC-4619-83E0- 32FCE5ADC37D@microso
ft.com...[color=darkred]
> Thanks for the feedback David. I presently have Administer rights for
> the
> database and all its objects and actually am the owner of all the subject
> database objects.
>
> Would it help if I create a different workgroup to set up these "new" test
> BE & FE databases instead of using the same workgroup that I'm using for
> my
> existing A97 on-line, multi-user, multi-facility database? When I try
> using
> the A2003 software's "Convert database" command and pick my A97FE for
> conversion, I get a message telling me I don't have the rights to do so.
> As I
> mentioned I got around this by creating the A2003FE version of the
> database
> by importing all objects. Do these facts shed any more light on the
> problems
> I'm encountering?
>
> Thanks again for your assistance!
>
> --
> Tim
>
>
> " david@epsomdotcomdot
au" wrote:
>

tiskal

2005-11-08, 4:15 pm

Thanks again David. This really helps clarify things for me. I will go the
route of setting up and using a completely different workgroup for creating
the A2000 FE database.
--
Tim

"david epsom dot com dot au" wrote:

> When you imported all the objects to a new database,
> you said that anyone who was a member of the A2003
> Admins Group could control security, (including Admin,
> the default user, who by default is a member of the
> default Admins Group)
>
> You now need to secure the new database. To do
> so you will need to import all of the objects into
> a secured database, while logged in to a secure
> workgroup as a secure user.
>
> Forget about having Administer rights for the
> database. That is not relevant. Forget about it:
> it is not relevant. The Administer rights for
> the database are not relevant.
>
> What is important is the Admins Group of the security
> workgroup used to create the database.
>
> The Admins Group of the security workgroup used
> to create the database is not something you can
> easily check or look at. It is not shown in the
> security settings. The only way to be sure about
> the Admins Group used to create a database is to
> plan carefully, act methodically, and record
> everything you do.
>
> Normally, you might plan to use the same workgroup
> for the A97 and the A2000 database. You would have
> to join the A97 workgroup to do that.
>
> Another common idea is to use a completely
> different workgroup for database creation,
> so that your distribution workgroup does not
> contain the Admins Group used to create the
> database. To do that you have to record how
> you create any security groups, so that you
> can create the security groups in both databases.
>
> microsoft.public.security is a good place to ask this kind of question.
>
> (david)
>
>
> "tiskal" <tiskal@discussions.microsoft.com> wrote in message
> news:B7EB8CD3-DDCC-4619-83E0- 32FCE5ADC37D@microso
ft.com...
>
>
>

Sponsored Links