471,593 Members | 1,717 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,593 software developers and data experts.

Permissions trouble transferring Access97 file to new computer

Tried this on microsoft.public.access.gettingstarted - no response -
perhaps more appropriate here.
I'm not a database user, simply helping someone get started with a new
computer.

The old computer (win98se) runs a database in MS Access 97 pro, with
all the attendant permissions etc. I can work on the database without
problems, once I've opened the file with the requisite user name and
password.

I cancelled the password and exported the access file to a new
filename and then loaded a copy into the new computer (xp) running
another copy of office 97 pro.

I'm able to start the database file on the new computer but no longer
have access to any of the components - eg, if I select a table to
open, I get:

couldn't read definitions; no read definitions permission for table or
query 'the filename'

I've spent some time amongst the various help items on security and,
frankly, I'm bewildered by the whole thing and haven't the time to
study it at length.

It seems that the key is to work at 'administration' level but I can't
work out how to do that.

Could someone please direct me to some *simple* recipe for letting my
friend operate her database on the new computer?

Apr 7 '06 #1
9 5099
John <no****@plusnet.com> wrote in
news:iq********************************@4ax.com:
Tried this on microsoft.public.access.gettingstarted - no
response - perhaps more appropriate here.
I'm not a database user, simply helping someone get started
with a new computer.

The old computer (win98se) runs a database in MS Access 97
pro, with all the attendant permissions etc. I can work on
the database without problems, once I've opened the file with
the requisite user name and password.

I cancelled the password and exported the access file to a new
filename and then loaded a copy into the new computer (xp)
running another copy of office 97 pro.

I'm able to start the database file on the new computer but no
longer have access to any of the components - eg, if I select
a table to open, I get:

couldn't read definitions; no read definitions permission for
table or query 'the filename'

I've spent some time amongst the various help items on
security and, frankly, I'm bewildered by the whole thing and
haven't the time to study it at length.

It seems that the key is to work at 'administration' level but
I can't work out how to do that.

Could someone please direct me to some *simple* recipe for
letting my friend operate her database on the new computer?

Access stores the login information in a .mdw file.

Search for any .mdw files on the old computer. Most probably the
creator of the database just altered the system.mdw instead of
creating a separate .mdw for their application.

If there is only the one file, system.mdw, rename the file on
the new computer, copy the one from the old computer to the new,
then test to see if everything works.

If there are several .mdw files on the old computer, you'll need
to see which one is used for the database. Before discussing
this try the other option first. If that doesn't help, write
back,

--
Bob Quintal

PA is y I've altered my email address.
Apr 7 '06 #2
Bob Quintal <rq******@sympatico.ca> wrote:

Access stores the login information in a .mdw file.

Search for any .mdw files on the old computer. Most probably the
creator of the database just altered the system.mdw instead of
creating a separate .mdw for their application.

If there is only the one file, system.mdw, rename the file on
the new computer, copy the one from the old computer to the new,
then test to see if everything works.

If there are several .mdw files on the old computer, you'll need
to see which one is used for the database. Before discussing
this try the other option first. If that doesn't help, write
back,

Many thanks, Bob. I'll report back when I've had another shot at the
job in a few days time.

--
John
Apr 7 '06 #3
Bob Quintal <rq******@sympatico.ca> wrote:

Access stores the login information in a .mdw file.

Search for any .mdw files on the old computer. Most probably the
creator of the database just altered the system.mdw instead of
creating a separate .mdw for their application.

If there is only the one file, system.mdw, rename the file on
the new computer, copy the one from the old computer to the new,
then test to see if everything works.

If there are several .mdw files on the old computer, you'll need
to see which one is used for the database. Before discussing
this try the other option first. If that doesn't help, write
back,


Right Bob.

The whole day gone and I've still not cracked it.

To recap, I've an old computer (win98) on which I can look at data,
using the password, in an MS Access 97 database.

I've copied the Access file *.mdb and the system.mdw file from the old
to a new computer (win xp) running Access 97.

I found system.mdw (the only one of three that was likely - the others
were a Quicken file and a Money file) in c:\windows\system folder.

I've put the .mdw file into the same folder (not the system32) in the
new computer. I can open the database but when I try to open a table
I get the message "couldn't read definitions; no read definitions
permission for table or
query 'name of dataset'

I've tried renaming the workgroup on the new computer the same as on
the old. No change.

I've tried making the data (and mdw file) path identical in new and
old computers.

The only difference is that, on the old pc, Office is in its usual
place c:\program files etc whereas on my new machine I've put Office
in a different folder, c:\microsoft office etc.

I've combed the goups literature and I've run out of ideas.

If you have any more, please post.

--
John
Apr 10 '06 #4
Br
John wrote:
Bob Quintal <rq******@sympatico.ca> wrote:
Access stores the login information in a .mdw file.

Search for any .mdw files on the old computer. Most probably the
creator of the database just altered the system.mdw instead of
creating a separate .mdw for their application.

If there is only the one file, system.mdw, rename the file on
the new computer, copy the one from the old computer to the new,
then test to see if everything works.

If there are several .mdw files on the old computer, you'll need
to see which one is used for the database. Before discussing
this try the other option first. If that doesn't help, write
back,


Right Bob.

The whole day gone and I've still not cracked it.

To recap, I've an old computer (win98) on which I can look at data,
using the password, in an MS Access 97 database.

I've copied the Access file *.mdb and the system.mdw file from the old
to a new computer (win xp) running Access 97.

I found system.mdw (the only one of three that was likely - the others
were a Quicken file and a Money file) in c:\windows\system folder.


Are you calling up the database via a shortcut? Check the command line used
to open the DB and see if it is referencing a workgroup file. Or, does the
password prompt come up for all MDBs? This would mean the workgroup is
attached statically so you need to open the Workgroup Administrator (look in
your office folder, actually it might be in the Windows system folder for
Access97....)
I've put the .mdw file into the same folder (not the system32) in the
new computer. I can open the database but when I try to open a table
I get the message "couldn't read definitions; no read definitions
permission for table or
query 'name of dataset'

I've tried renaming the workgroup on the new computer the same as on
the old. No change.

I've tried making the data (and mdw file) path identical in new and
old computers.

You still have to point Access to this workgroup file. You can either do
this via the Access command line

eg.

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" "C:\Program
Files\BIGCare\BigCare.mde" /wrkgrp "C:\Documents and Settings\brad\My
Documents\Ministry\BIGCare\Data\BigCare.mdw"

(You must use the full Office path)

, or use the Workgroup Administrator (part of Office) to point to it (But
you will need to point it back to the default system.mdw when using other
MDBs).

Putting it in the same folder does abssolutely nothing.
The only difference is that, on the old pc, Office is in its usual
place c:\program files etc whereas on my new machine I've put Office
in a different folder, c:\microsoft office etc.
Makes no difference. I run three versions of Office all in different
folders.
I've combed the goups literature and I've run out of ideas.

If you have any more, please post.


How big is the DB? If you are still having problems and if it's not too
large, ZIP it and send it to me. I will try to break the security and import
everything into a new DB without security. bradleyATcomcenDOTcomDOTau

This should be a very last resort and shouldn't be required given you still
have the original MDW available.
--
regards,

Br@dley
Apr 10 '06 #5
"Br@dley" <do***********@google.com> wrote:
Are you calling up the database via a shortcut? Check the command line used
to open the DB and see if it is referencing a workgroup file. Or, does the
password prompt come up for all MDBs? This would mean the workgroup is
attached statically so you need to open the Workgroup Administrator (look in
your office folder, actually it might be in the Windows system folder for
Access97....)
Two ways - starting Access 97, 'opening an existing database', choose
file. If I choose the sample, Northwind, all is normal. If I choose
the problematic database (Parish_99.mdb), I'm asked for a password.
The PW gets me to a set of tabs. I select 'tables' and highlight
'households'. I click on 'open' and get the error message 'Couldn't
read definitions etc.'

I've made a shortcut to the target:

"C:\Microsoft Office\office\msaccess.exe"
"C:\A_Parish\Ruth\Register\Parish\Parish_99.md b"
/wrkgrp c:\windows\system\system.mdw

and 'start in' "c:\microsoft office\office"

this opens Access 97 and asks for a password with the same result as
above.

So the results from the two methods are consistent.

How big is the DB?
674k
If you are still having problems and if it's not too
large, ZIP it and send it to me. I will try to break the security and import
everything into a new DB without security. bradleyATcomcenDOTcomDOTau

This should be a very last resort and shouldn't be required given you still
have the original MDW available.


Very kind offer and thankyou but I don't have permission to release
the data to anyone else. If we get desperate we'll have to start the
database again from scratch (aaaarghhh) as the ethics rule out
passing out the file.

Thanks for your help. Any other ideas? I'm troubled by the thought
that there are so many differences between the two situations in which
the database behaves differently. O.S., file structure, directory
structure, winodows workgroup name, windows administrator and so forth
but I've tried to simulate the same conditions as far as possible,
changing the name of my computer (and suffering grief from my backup
software which wants me to re-register :( ) and windows workgroup,
creating a windows guest with the same name and password as that on
the 'working' machine, using the shortcut to run the programme as a
win 98 programme.

Nothing works although I have had a few different error messages when
I try some of these wilder things.

It's as though there is a missing piece of information stored
somewhere on the original computer. Security schemes will see the end
of the world as we know it - I have enough problems remembering all
the security questions on my savings accounts :(

Sorry, I'm being a grumpy old man and shouldn't moan about 'progress'.

--
John
Apr 11 '06 #6
Br
John wrote:
"Br@dley" <do***********@google.com> wrote:
Are you calling up the database via a shortcut? Check the command
line used to open the DB and see if it is referencing a workgroup
file. Or, does the password prompt come up for all MDBs? This would
mean the workgroup is attached statically so you need to open the
Workgroup Administrator (look in your office folder, actually it
might be in the Windows system folder for Access97....)
Two ways - starting Access 97, 'opening an existing database', choose
file. If I choose the sample, Northwind, all is normal. If I choose
the problematic database (Parish_99.mdb), I'm asked for a password.
The PW gets me to a set of tabs. I select 'tables' and highlight
'households'. I click on 'open' and get the error message 'Couldn't
read definitions etc.'


Sounds like the original system.mdw has been modified wrongly?

Actually, are you only being asked for a password and not a username as
well? That'd be a database password rather than workgroup security....

Have you tried holding down the shift key before clicking OK after entering
the password? This will take you to the database window. Try this and open
the Access security dialogs and see if you can give yourself permissions to
everything... or open objects in design view.
I've made a shortcut to the target:

"C:\Microsoft Office\office\msaccess.exe"
"C:\A_Parish\Ruth\Register\Parish\Parish_99.md b"
/wrkgrp c:\windows\system\system.mdw

and 'start in' "c:\microsoft office\office"

this opens Access 97 and asks for a password with the same result as
above.

So the results from the two methods are consistent.
Sounds like you are logging in with a user/pass that doesn't have
permissions to everything?
How big is the DB?


674k
If you are still having problems and if it's not too
large, ZIP it and send it to me. I will try to break the security
and import everything into a new DB without security.
bradleyATcomcenDOTcomDOTau

This should be a very last resort and shouldn't be required given
you still have the original MDW available.


Very kind offer and thankyou but I don't have permission to release
the data to anyone else. If we get desperate we'll have to start the
database again from scratch (aaaarghhh) as the ethics rule out
passing out the file.


Fair enough. I hesitant to share the "hack" as well:)
Thanks for your help. Any other ideas? I'm troubled by the thought
that there are so many differences between the two situations in which
the database behaves differently.
That shouldn't matter. As long as you are pointing to the right workgroup
file and can log in as a user with permissions therre shouldn't be a
problem.
O.S., file structure, directory
structure, winodows workgroup name, windows administrator and so forth
but I've tried to simulate the same conditions as far as possible,
changing the name of my computer (and suffering grief from my backup
software which wants me to re-register :( ) and windows workgroup,
creating a windows guest with the same name and password as that on
the 'working' machine, using the shortcut to run the programme as a
win 98 programme.

Nothing works although I have had a few different error messages when
I try some of these wilder things.

It's as though there is a missing piece of information stored
somewhere on the original computer. Security schemes will see the end
of the world as we know it - I have enough problems remembering all
the security questions on my savings accounts :(

Sorry, I'm being a grumpy old man and shouldn't moan about 'progress'.


I don't quite understand the problems you are having.

If you have the original workgroup file then it should work the same way if
you are using that workgroup file (either from the command-line or through
the workgroup adminstrator). It doesn't matter where the file is storeed on
the PC (or even on a network share).
--
regards,

Br@dley
Apr 11 '06 #7
"Br@dley" <do***********@google.com> wrote:
John wrote:
"Br@dley" <do***********@google.com> wrote:
Are you calling up the database via a shortcut? Check the command
line used to open the DB and see if it is referencing a workgroup
file. Or, does the password prompt come up for all MDBs? This would
mean the workgroup is attached statically so you need to open the
Workgroup Administrator (look in your office folder, actually it
might be in the Windows system folder for Access97....)
Two ways - starting Access 97, 'opening an existing database', choose
file. If I choose the sample, Northwind, all is normal. If I choose
the problematic database (Parish_99.mdb), I'm asked for a password.
The PW gets me to a set of tabs. I select 'tables' and highlight
'households'. I click on 'open' and get the error message 'Couldn't
read definitions etc.'


Sounds like the original system.mdw has been modified wrongly?

Actually, are you only being asked for a password and not a username as
well? That'd be a database password rather than workgroup security....


Yes, it is the database password, no username being asked for.
Have you tried holding down the shift key before clicking OK after entering
the password? This will take you to the database window. Try this and open
the Access security dialogs and see if you can give yourself permissions to
everything... or open objects in design view.
Shift key doesn't change anything. The correct pw simply reveals the
set of tabs including tables, queries etc.

I've made a shortcut to the target:

"C:\Microsoft Office\office\msaccess.exe"
"C:\A_Parish\Ruth\Register\Parish\Parish_99.md b"
/wrkgrp c:\windows\system\system.mdw

and 'start in' "c:\microsoft office\office"

this opens Access 97 and asks for a password with the same result as
above.

So the results from the two methods are consistent.
Sounds like you are logging in with a user/pass that doesn't have
permissions to everything?


Doesn't have permissions to see *any* data other than the named groups
of data for which one can view tables, queries etc.

If you have the original workgroup file then it should work the same way if
you are using that workgroup file (either from the command-line or through
the workgroup adminstrator). It doesn't matter where the file is storeed on
the PC (or even on a network share).


OK, looks as though I've reached the end of the line.

Apr 11 '06 #8
On Tue, 11 Apr 2006 07:52:51 +1000, "Br@dley"
<do***********@google.com> wrote:
John wrote:
Bob Quintal <rq******@sympatico.ca> wrote:

Access stores the login information in a .mdw file.

Search for any .mdw files on the old computer. Most probably the
creator of the database just altered the system.mdw instead of
creating a separate .mdw for their application.

If there is only the one file, system.mdw, rename the file on
the new computer, copy the one from the old computer to the new,
then test to see if everything works.

If there are several .mdw files on the old computer, you'll need
to see which one is used for the database. Before discussing
this try the other option first. If that doesn't help, write
back,


Right Bob.

The whole day gone and I've still not cracked it.

To recap, I've an old computer (win98) on which I can look at data,
using the password, in an MS Access 97 database.

I've copied the Access file *.mdb and the system.mdw file from the old
to a new computer (win xp) running Access 97.

I found system.mdw (the only one of three that was likely - the others
were a Quicken file and a Money file) in c:\windows\system folder.


Are you calling up the database via a shortcut? Check the command line used
to open the DB and see if it is referencing a workgroup file. Or, does the
password prompt come up for all MDBs? This would mean the workgroup is
attached statically so you need to open the Workgroup Administrator (look in
your office folder, actually it might be in the Windows system folder for
Access97....)
I've put the .mdw file into the same folder (not the system32) in the
new computer. I can open the database but when I try to open a table
I get the message "couldn't read definitions; no read definitions
permission for table or
query 'name of dataset'

I've tried renaming the workgroup on the new computer the same as on
the old. No change.

I've tried making the data (and mdw file) path identical in new and
old computers.

You still have to point Access to this workgroup file. You can either do
this via the Access command line

eg.

"C:\Program Files\Microsoft Office 2000\Office\MSACCESS.EXE" "C:\Program
Files\BIGCare\BigCare.mde" /wrkgrp "C:\Documents and Settings\brad\My
Documents\Ministry\BIGCare\Data\BigCare.mdw"

(You must use the full Office path)

I had the same problem and this worked. This is great info!
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
Apr 14 '06 #9
John <no****@plusnet.com> wrote:
OK, looks as though I've reached the end of the line.


Not true, fortunately.

Problem now solved.

For those who meet the same problem:

Recap - Secured database file on old win98se PC - I had user rights.
I copied the file to a new xp pc together with system.mdw (put in new
Windows/System folder). I could not access the database on the new PC
- 'couldn't read definitions; no read definitions permission for table
or query 'filename' . Attempts to enter the database on the new PC,
even with the securing originator's name and password, failed with the
same message.

Solution: Using the originator's identity (name and pw) open new
database on the old PC and 'file/get external data etc' to import the
original database stuff into the new. Transfer this database file and
system.mdw to new PC - all well. All that is now required is to
re-secure the new version on the new PC.

After I had done this, I found a MS FAQ with the official method of
de-securing a database

http://support.microsoft.com/default...ent/secfaq.asp

item 34.

As another helpful aside, I spent 7 quid on a used copy of the MS
Access Bible, all 1000 pages of it - not one word about security!

Solution to that one is that you need 'the gold edition' of this
'bible', which has 1500 pages. :(

Thanks again for all the kindly help.
Apr 19 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Hugh Welford | last post: by
10 posts views Thread by John Salerno | last post: by
1 post views Thread by Jeremy.Campbell | last post: by
30 posts views Thread by Adam Baker | last post: by
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.