Can't move split database.

[wdsnews]

I'm slowly coming up to speed on Access... but slowly. In Paradox, it was
possible to redefine the Work folder and move a database to a new location.
But I'm having trouble doing the same thing with Access.

I've recently split our database in preparation for multi-user support.
Before the MDB split, it was possible to copy the database from the network
drive to the local C: drive and use it on the C: drive (to allow other users
to use it for read-only purposes). Now, when we attempt to use it on drive
C:, forms continue looking to the network drive for their data. For example
the People Form returns an error that it's unable to access the table on W:.

What do I need to change?

 

[John W. Vinson]

I've recently split our database in preparation for multi-user support.
Before the MDB split, it was possible to copy the database from the network
drive to the local C: drive and use it on the C: drive (to allow other users
to use it for read-only purposes). Now, when we attempt to use it on drive
C:, forms continue looking to the network drive for their data. For example
the People Form returns an error that it's unable to access the table on W:.

What do I need to change?

Use Tools... Database Utilities... Linked Table Manager to relink to the new
location of the backend.

If you navigate to the backend via Network Neighborhood rather than via mapped
drive names, the frontend can be moved to any computer on the network
regardless of that computer's drive mappings.

 

[Albert D. Kallal]

I explain the split concept in detail here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

The above also explains how you correctly now add new tables, and make
design changes to the back end (so, its a good read).

In a sense, think of your front end part as the program part, and the back
end part the data file.

The "links" remain permanent in place even when you copy/move the front end,
you have to use the linked table manager to change the front end to "point"
to the new correct location of the data file (back end).

Also, note the comments in the above article that suggests NOT used mapped
drives, but using what is called unc path names.

 

[wdsnews]

Thank you. The Linked Table Manager sounds like what I was missing.

I support a lot of networks and mapped drives have provided a big advantage
over the years. Where UNC names might require each network and resource to
use the same name, mapped drives work everywhere. Users naturally
understand the concept of a "Work" folder named [W:]. It even worked back
in the DOS (SUBST) and Novell days.

This weekend I dug out an old backup script I had written to maintain an
archive of 10 copies of something by deleting certain intermediate versions
so that each copy is twice as old as the previous. With just ten copies you
can go back in time several months. That script is over 15 years old and
still works without having to edit any UNC paths.

Nevertheless, there are times when I prefer UNC paths. Thanks for your
help.

 

[wdsnews]

Albert,

Thank you. That's a very well done article. I look forward to burying
myself in it tomorrow. Thank you for your help.

 

[David W. Fenton]

I support a lot of networks and mapped drives have provided a big
advantage over the years. Where UNC names might require each
network and resource to use the same name, mapped drives work
everywhere. Users naturally understand the concept of a "Work"
folder named [W:]. It even worked back in the DOS (SUBST) and
Novell days.

I never use mapped drives unless forced to. They are an artifact of
the past, something that should be abandoned entirely.

The problem you allued to ("UNC names might require each network and
resource to use the same name") is caused by poor planning of the
server. Shares should be mapped according to function and user
groups that need access, rather than just mapping the root of the
server's data drive. For instance, once client of mine had shares
something like this:

Administrative
Finance
Clients
Software
Public

And so forth. Or maybe Finance was under Admin (can't remember
exactly). Security groups were structured to reflect the
responsibilities of the employees and they were then given
appropriate access to shares according to their needs. That meant
that some Admin folders were read-only, and some were entirely off
limits to certain users.

It was very easy to browse the server and get
where you wanted to go, much easier than if the data drive had been
mapped to root.

BTW, the example cited above was implemented in 1998.