Migration and authorisations

[John]

Recently we migrated to a new hard- and software environment. Also, all data
has moved to a new network drive, with a new name. We have one mdb and an
associated mdw that now gives us trouble. If the users try to open the mdb
they get the message (translated from Dutch):

"you do not have the correct authorisations for the use of object 'G:\...
\OurFileName.md b '. Contact you system manager or the person who has made
the object, to establish the correct authorisations for you."

We suspect that there is hard path reference in the mdb that points to the
old location of
the mdw (with the old drive's name). I have never worked with
'authorisations ' or working grouops and the builder of this application is
gone and can not be reached.

Does anyone have an idea on how we can get the mdb to run again? Even if we
would lose the whole autorisation and workgroup functionality in this mdb,
that would be better than nothing being able to access the mdb at all.

Temporarily moving back to the old network drive is not an option.

Thanks in advance,
john

[Last Boy Scout]

John wrote:

Recently we migrated to a new hard- and software environment. Also, all data
has moved to a new network drive, with a new name. We have one mdb and an
associated mdw that now gives us trouble. If the users try to open the mdb
they get the message (translated from Dutch):

"you do not have the correct authorisations for the use of object 'G:\...
\OurFileName.md b '. Contact you system manager or the person who has made
the object, to establish the correct authorisations for you."

We suspect that there is hard path reference in the mdb that points to the
old location of
the mdw (with the old drive's name). I have never worked with
'authorisations ' or working grouops and the builder of this application is
gone and can not be reached.

Does anyone have an idea on how we can get the mdb to run again? Even if we
would lose the whole autorisation and workgroup functionality in this mdb,
that would be better than nothing being able to access the mdb at all.

Temporarily moving back to the old network drive is not an option.

Thanks in advance,
john

Either way you still have to know how to access the security settings.
You did not mention the database and version or anything like that so
you are probably not going to get much usable help. A lot depends on
why you split the database up on the two drives. If they are in two
separate databases you may have two separate sets of security. Some
networking server software would let you join the two drives into one
volume and treat it all as one location or object if it was on the same
server.

My suggestion is hire a consultant that knows the database and/or
application or some kind of professional outfit that can make some
suggestions or help you to accomplish what you want to do. It may save
you money and time in the long run. You dont want to find out months
from now that you are going to have redo your conversion because you
have missing writes to the table and corrupt data.

[John]

Thanks for your reply.

You did not mention the database and version or anything like that so you
are probably not going to get much usable help.

It's an Access 2000 mdb and we now use Access 2002.

A lot depends on why you split the database up on the two drives. If they
are in two separate databases you may have two separate sets of security.
Some networking server software would let you join the two drives into one
volume and treat it all as one location or object if it was on the same
server.

I don't know how things were made on the former server or why. I only know
that the mdb and mdw are both in the same folder. This morning a co worker
copied the mdb and mdw to a C-drive and simulated the old path with the dos
substitute command. That didn't change anything: same message.

Seems we have to inform Houston and bring in the helicopters to hunt down
the creator of this database :-)

john

"Last Boy Scout" <Ba*****@whiteh ouse.govschreef in bericht
news:Ey******** ********@newsfe 04.lga...

John wrote:

>Recently we migrated to a new hard- and software environment. Also, all
data has moved to a new network drive, with a new name. We have one mdb
and an associated mdw that now gives us trouble. If the users try to open
the mdb they get the message (translated from Dutch):

"you do not have the correct authorisations for the use of object 'G:\...
\OurFileName.m db '. Contact you system manager or the person who has made
the object, to establish the correct authorisations for you."

We suspect that there is hard path reference in the mdb that points to
the old location of
the mdw (with the old drive's name). I have never worked with
'authorisation s' or working grouops and the builder of this application
is gone and can not be reached.

Does anyone have an idea on how we can get the mdb to run again? Even if
we would lose the whole autorisation and workgroup functionality in this
mdb, that would be better than nothing being able to access the mdb at
all.

Temporarily moving back to the old network drive is not an option.

Thanks in advance,
john

Either way you still have to know how to access the security settings. You
did not mention the database and version or anything like that so you are
probably not going to get much usable help. A lot depends on why you
split the database up on the two drives. If they are in two separate
databases you may have two separate sets of security. Some networking
server software would let you join the two drives into one volume and
treat it all as one location or object if it was on the same server.

My suggestion is hire a consultant that knows the database and/or
application or some kind of professional outfit that can make some
suggestions or help you to accomplish what you want to do. It may save
you money and time in the long run. You dont want to find out months from
now that you are going to have redo your conversion because you have
missing writes to the table and corrupt data.

[Larry Linson]

Actually, it may be that all you need to do is to use the Linked Table
Manager to relink the tables to the "back end" database in its new location.
Each user will have to have Create, Delete, Read, and Write access to the
folder where the back end datastore is stored. The messages you are seeing
do not _necessarily_ indicate a problem with Access security.

If you will search at http://support.microsoft.com for the "Orders and
Solutions Sample Database", the Solutions sample (which hasn't been updated
since Access 2000, but still is very useful) has an example of relinking
tables at startup. On my linked databases, I also employ the solution
donated by Ken Getz, that is available to the Access user community at
http://www.mvps.org/access/api/api0001.htm to allow the user to browse and
find the backend.

Larry Linson
Microsoft Access MVP
"John" <[e-mail] te in message
news:f0******** ***@textnews.wa nadoo.nl...

Thanks for your reply.

>You did not mention the database and version or anything like that so you
are probably not going to get much usable help.

It's an Access 2000 mdb and we now use Access 2002.

>A lot depends on why you split the database up on the two drives. If
they are in two separate databases you may have two separate sets of
security. Some networking server software would let you join the two
drives into one volume and treat it all as one location or object if it
was on the same server.

I don't know how things were made on the former server or why. I only know
that the mdb and mdw are both in the same folder. This morning a co worker
copied the mdb and mdw to a C-drive and simulated the old path with the
dos substitute command. That didn't change anything: same message.

Seems we have to inform Houston and bring in the helicopters to hunt down
the creator of this database :-)

john

"Last Boy Scout" <Ba*****@whiteh ouse.govschreef in bericht
news:Ey******** ********@newsfe 04.lga...

>John wrote:

>>Recently we migrated to a new hard- and software environment. Also, all
data has moved to a new network drive, with a new name. We have one mdb
and an associated mdw that now gives us trouble. If the users try to
open the mdb they get the message (translated from Dutch):

"you do not have the correct authorisations for the use of object
'G:\... \OurFileName.md b '. Contact you system manager or the person who
has made the object, to establish the correct authorisations for you."

We suspect that there is hard path reference in the mdb that points to
the old location of
the mdw (with the old drive's name). I have never worked with
'authorisatio ns' or working grouops and the builder of this application
is gone and can not be reached.

Does anyone have an idea on how we can get the mdb to run again? Even if
we would lose the whole autorisation and workgroup functionality in this
mdb, that would be better than nothing being able to access the mdb at
all.

Temporarily moving back to the old network drive is not an option.

Thanks in advance,
john

Either way you still have to know how to access the security settings.
You did not mention the database and version or anything like that so you
are probably not going to get much usable help. A lot depends on why you
split the database up on the two drives. If they are in two separate
databases you may have two separate sets of security. Some networking
server software would let you join the two drives into one volume and
treat it all as one location or object if it was on the same server.

My suggestion is hire a consultant that knows the database and/or
application or some kind of professional outfit that can make some
suggestions or help you to accomplish what you want to do. It may save
you money and time in the long run. You dont want to find out months
from now that you are going to have redo your conversion because you have
missing writes to the table and corrupt data.

[John]

Thanks! That sounds hopeful. I'll check it out.

"Larry Linson" <bo*****@localh ost.notschreef in bericht
news:krzWh.609$ nR1.521@trnddc0 6...

Actually, it may be that all you need to do is to use the Linked Table
Manager to relink the tables to the "back end" database in its new
location. Each user will have to have Create, Delete, Read, and Write
access to the folder where the back end datastore is stored. The messages
you are seeing do not _necessarily_ indicate a problem with Access
security.

If you will search at http://support.microsoft.com for the "Orders and
Solutions Sample Database", the Solutions sample (which hasn't been
updated since Access 2000, but still is very useful) has an example of
relinking tables at startup. On my linked databases, I also employ the
solution donated by Ken Getz, that is available to the Access user
community at http://www.mvps.org/access/api/api0001.htm to allow the user
to browse and find the backend.

Larry Linson
Microsoft Access MVP
"John" <[e-mail] te in message
news:f0******** ***@textnews.wa nadoo.nl...

>Thanks for your reply.

>>You did not mention the database and version or anything like that so
you are probably not going to get much usable help.

It's an Access 2000 mdb and we now use Access 2002.

>>A lot depends on why you split the database up on the two drives. If
they are in two separate databases you may have two separate sets of
security. Some networking server software would let you join the two
drives into one volume and treat it all as one location or object if it
was on the same server.

I don't know how things were made on the former server or why. I only
know that the mdb and mdw are both in the same folder. This morning a co
worker copied the mdb and mdw to a C-drive and simulated the old path
with the dos substitute command. That didn't change anything: same
message.

Seems we have to inform Houston and bring in the helicopters to hunt down
the creator of this database :-)

john

"Last Boy Scout" <Ba*****@whiteh ouse.govschreef in bericht
news:Ey******* *********@newsf e04.lga...

>>John wrote:
Recently we migrated to a new hard- and software environment. Also, all
data has moved to a new network drive, with a new name. We have one mdb
and an associated mdw that now gives us trouble. If the users try to
open the mdb they get the message (translated from Dutch):

"you do not have the correct authorisations for the use of object
'G:\... \OurFileName.md b '. Contact you system manager or the person
who has made the object, to establish the correct authorisations for
you."

We suspect that there is hard path reference in the mdb that points to
the old location of
the mdw (with the old drive's name). I have never worked with
'authorisati ons' or working grouops and the builder of this application
is gone and can not be reached.

Does anyone have an idea on how we can get the mdb to run again? Even
if we would lose the whole autorisation and workgroup functionality in
this mdb, that would be better than nothing being able to access the
mdb at all.

Temporaril y moving back to the old network drive is not an option.

Thanks in advance,
john
Either way you still have to know how to access the security settings.
You did not mention the database and version or anything like that so
you are probably not going to get much usable help. A lot depends on
why you split the database up on the two drives. If they are in two
separate databases you may have two separate sets of security. Some
networking server software would let you join the two drives into one
volume and treat it all as one location or object if it was on the same
server.

My suggestion is hire a consultant that knows the database and/or
application or some kind of professional outfit that can make some
suggestions or help you to accomplish what you want to do. It may save
you money and time in the long run. You dont want to find out months
from now that you are going to have redo your conversion because you
have missing writes to the table and corrupt data.

[John]

In our citrix-environment users can't make short cuts with reference to the
Access-exe. One of our administrators made a vbs script that does reference
to the Access-exe, the mdw location, and the mdb location and made the
application works again.

Thanks,
john

"John" <[e-mail] ef in bericht
news:f0******** ***@textnews.wa nadoo.nl...

Thanks! That sounds hopeful. I'll check it out.

"Larry Linson" <bo*****@localh ost.notschreef in bericht
news:krzWh.609$ nR1.521@trnddc0 6...

>Actually, it may be that all you need to do is to use the Linked Table
Manager to relink the tables to the "back end" database in its new
location. Each user will have to have Create, Delete, Read, and Write
access to the folder where the back end datastore is stored. The messages
you are seeing do not _necessarily_ indicate a problem with Access
security.

If you will search at http://support.microsoft.com for the "Orders and
Solutions Sample Database", the Solutions sample (which hasn't been
updated since Access 2000, but still is very useful) has an example of
relinking tables at startup. On my linked databases, I also employ the
solution donated by Ken Getz, that is available to the Access user
community at http://www.mvps.org/access/api/api0001.htm to allow the user
to browse and find the backend.

Larry Linson
Microsoft Access MVP
"John" <[e-mail] te in message
news:f0******* ****@textnews.w anadoo.nl...

>>Thanks for your reply.

You did not mention the database and version or anything like that so
you are probably not going to get much usable help.

It's an Access 2000 mdb and we now use Access 2002.

A lot depends on why you split the database up on the two drives. If
they are in two separate databases you may have two separate sets of
security. Some networking server software would let you join the two
drives into one volume and treat it all as one location or object if
it was on the same server.

I don't know how things were made on the former server or why. I only
know that the mdb and mdw are both in the same folder. This morning a co
worker copied the mdb and mdw to a C-drive and simulated the old path
with the dos substitute command. That didn't change anything: same
message.

Seems we have to inform Houston and bring in the helicopters to hunt
down the creator of this database :-)

john

"Last Boy Scout" <Ba*****@whiteh ouse.govschreef in bericht
news:Ey****** **********@news fe04.lga...
John wrote:
Recently we migrated to a new hard- and software environment. Also,
all data has moved to a new network drive, with a new name. We have
one mdb and an associated mdw that now gives us trouble. If the users
try to open the mdb they get the message (translated from Dutch):
>
"you do not have the correct authorisations for the use of object
'G:\... \OurFileName.md b '. Contact you system manager or the person
who has made the object, to establish the correct authorisations for
you."
>
We suspect that there is hard path reference in the mdb that points to
the old location of
the mdw (with the old drive's name). I have never worked with
'authorisat ions' or working grouops and the builder of this
applicati on is gone and can not be reached.
>
Does anyone have an idea on how we can get the mdb to run again? Even
if we would lose the whole autorisation and workgroup functionality in
this mdb, that would be better than nothing being able to access the
mdb at all.
>
Temporari ly moving back to the old network drive is not an option.
>
Thanks in advance,
john
Either way you still have to know how to access the security settings.
You did not mention the database and version or anything like that so
you are probably not going to get much usable help. A lot depends on
why you split the database up on the two drives. If they are in two
separate databases you may have two separate sets of security. Some
networking server software would let you join the two drives into one
volume and treat it all as one location or object if it was on the
same server.

My suggestion is hire a consultant that knows the database and/or
applicatio n or some kind of professional outfit that can make some
suggestion s or help you to accomplish what you want to do. It may save
you money and time in the long run. You dont want to find out months
from now that you are going to have redo your conversion because you
have missing writes to the table and corrupt data.