473,387 Members | 1,501 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 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 5223
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: Hugh Welford | last post by:
Hi, I have installed IIS5 on my machine so that I can do offline asp web development. (using WIN XP PRO). My machine is called "development" I have published an on-line working web to...
2
by: Fran Tirimo | last post by:
I am developing a small website using ASP scripts to format data retrieved from an Access database. It will run on a Windows 2003 server supporting FrontPage extensions 2002 hosted by the company...
10
by: John Salerno | last post by:
I always read about how you need to set certain file permissions (for cgi files, for example), but it's never been clear to me *how* you do this. I know you can run the line chmod 755...
1
by: IamKJVonly | last post by:
I have office 97 which includes access97 and have built many access97 databases and use VB4 as the front end. I have just gotten a new computer which has 1 gig of memory on it and when I try to...
4
by: Rico | last post by:
Hello, I have an MDE application where I use a bound object frame to display an image. This frame is updatable and bested on the contents of an OLE field. My problem is, some images display as...
1
by: Jeremy.Campbell | last post by:
I am trying to add a picture to a form that is visible depending on certain criteria. The picture works perfectly on my computer, but on other users computers this image is either black or...
30
by: Adam Baker | last post by:
Hello, I'm writing a site where a handful of people will be able to edit the content using PHP scripts (FCKeditor). The content is stored as individual files in a directory. I'd like to validate...
2
by: JimLad | last post by:
Hi, First of all I didn't design this website, but I have been asked to fix it with the minimum fuss! Website is using .NET on IIS6 with an Excel Interop to produce reports. The website...
6
by: Pep | last post by:
Firstly, I'm not sure if this is the right group for this query, so please forgive me if I am wrong. My problem is that most users I distribute my software to cannot install it on their systems...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...

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.