Network drops linked tables

[DSmith]

In my database, there are a few linked tables. These links will not hold
over our network. They only hold on the computer where the database
resides.The links can be re-established each day on each network computer
but this is getting old. Is there anything I can do? Any help would be
appreciated.

Thanks,
Donna

 

[Galen Boyer]

If your database is used by more than one person at a time it's
usually a good idea to split it into a back end (containing
just the data) and front end (with queries, forms, reports, and
the rest of the user interface). Give each user a copy of the
front end, all linked to the one back end. See Access Help for
more information.

This sounds like a great idea. My hesitation is that my
datamodel is still quite influx and I'm worried that as I have to
modify the structures, then all links will be invalidated.

I guess I could put the database with queries, forms, reports and
the rest in VSS and tell the users to check out the latest from
VSS. But, there would be a certain amount of time which the
client access databases would be unusable, while I modified the
datastore and upgraded the client copys.

Is this how others handle it?

 

[John Nurick]

Updating the client copies is quite simple. I do it by having the
shortcuts on the users computer download the FE from the server each
time they launch the program: this means that they always have the
latest version in guaranteed good order.

There are also utilities that check the version before launching and
download a new one if it exists; IIRC Tony Toews has an Auto FE updater
at http://www.granite.ab.ca/accsmstr.htm.

As for the back end: you can do most of your development work on a
separate copy of it, but if you need to restructure the existing tables
there will be times when you have to give yourself exclusive access to
the back end. (That's what weekends are for<g>).

This sounds like a great idea. My hesitation is that my
datamodel is still quite influx and I'm worried that as I have to
modify the structures, then all links will be invalidated.

I guess I could put the database with queries, forms, reports and
the rest in VSS and tell the users to check out the latest from
VSS. But, there would be a certain amount of time which the
client access databases would be unusable, while I modified the
datastore and upgraded the client copys.

Is this how others handle it?

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

 

[DSmith]

John,
Our network is peer to peer. Would using the UNC still be true? What does
UNC stand for? I have thought about splitting the database but would like to
read more on the pros and cons. Although, our database is large it does what
we need it to do without any corruption or problems in 9 years. I'd hate to
cause any due to ignorance on my part.

Thanks for your help,
Donna

Hi Donna,

Is it possible that the network share in question is being mapped to
different drive letters by different users? To exclude this possibility,
set up the linked tables using the UNC locator rather than the drive
letter, e.g.
\\COMPUTERNAME\ShareName\Folder\Subfolder\File.mdb

If your database is used by more than one person at a time it's usually
a good idea to split it into a back end (containing just the data) and
front end (with queries, forms, reports, and the rest of the user
interface). Give each user a copy of the front end, all linked to the
one back end. See Access Help for more information.

In my database, there are a few linked tables. These links will not hold
over our network. They only hold on the computer where the database
resides.The links can be re-established each day on each network computer
but this is getting old. Is there anything I can do? Any help would be
appreciated.

Thanks,
Donna

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

 

[DSmith]

John,
I have looked at our peer-to-peer network which uses 98 2nd Ed. It is set-up
to share the C-drive on each computer and not just specific files. Is this
the problem? Where would we use your example of a naming convention to share
the database without using drive letters? I have read Microsoft's Support on
setting up a network using 98 but did not come across any information that
would help setup sharing a file without using a drive letter.

I'll practice splitting a copy of our database to see if I run into any
problems.

Thanks again,
Donna

John,
Our network is peer to peer. Would using the UNC still be true?
Yes.

What does UNC stand for?

Uniform, or universal, naming convention, or some such.

I have thought about splitting the database but would like to
read more on the pros and cons. Although, our database is large it does what
we need it to do without any corruption or problems in 9 years. I'd hate to
cause any due to ignorance on my part.

Splitting tends to prevent corruption and other problems with multi-user
databases ... so if you're not having any problems the case for
splitting isn't quite so strong. I'd still be inclined to do it as a
precaution, especially if the database is large and precious.


John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

 

[John Nurick]

Donna,

What I suspect might be causing the problem is this.

Suppose the database is on the C: drive of the computer whose name is
"ROSS", in the file
C:\data\somefolder\ourdatabase.mdb.
And the data for the linked tables is on the same drive, in
C:\data\otherfolder\linkeddata.mdb

Suppose also that (as you've said) the whole of ROSS's C drive is shared
under the name CDRIVE.

If you open the database on ROSS, the linked tables can point to
C:\data\otherfolder\linkeddata.mdb

But if you're working on another another machine (let's call it
"CROMARTY"), C: refers to SHAW's C drive, and you have to map ROSS's
shared C drive - for which the UNC name is \\ROSS\CDRIVE to some other
letter (e.g. F. This means that when someone opens the database on
CROMARTY, the linked tables will need to point to
F:\data\otherfolder\linkeddata.mdb

And if there's another machine ("FIFE") on which \\ROSS\CDRIVE is mapped
to E: instead of F:, the linked tables will need to point to
E:\data\otherfolder\linkeddata.mdb

On the other hand, if you point the linked tables at
\\ROSS\CDRIVE\data\otherfolder\linkeddata.mdb
they will work on all machines without alteration.

John,
I have looked at our peer-to-peer network which uses 98 2nd Ed. It is set-up
to share the C-drive on each computer and not just specific files. Is this
the problem? Where would we use your example of a naming convention to share
the database without using drive letters? I have read Microsoft's Support on
setting up a network using 98 but did not come across any information that
would help setup sharing a file without using a drive letter.

I'll practice splitting a copy of our database to see if I run into any
problems.

Thanks again,
Donna

John,
Our network is peer to peer. Would using the UNC still be true?
Yes.

What does UNC stand for?

Uniform, or universal, naming convention, or some such.

I have thought about splitting the database but would like to
read more on the pros and cons. Although, our database is large it does what
we need it to do without any corruption or problems in 9 years. I'd hate to
cause any due to ignorance on my part.

Splitting tends to prevent corruption and other problems with multi-user
databases ... so if you're not having any problems the case for
splitting isn't quite so strong. I'd still be inclined to do it as a
precaution, especially if the database is large and precious.


John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

 

[DSmith]

John,
Thanks for all your help. I recently updated Office 2000 with SP3 and when I
went back to these links, they are now working. So it looks like the update
made Access more stable since we have not done anything to the network.

Thanks again,
Donna

Donna,

What I suspect might be causing the problem is this.

Suppose the database is on the C: drive of the computer whose name is
"ROSS", in the file
C:\data\somefolder\ourdatabase.mdb.
And the data for the linked tables is on the same drive, in
C:\data\otherfolder\linkeddata.mdb

Suppose also that (as you've said) the whole of ROSS's C drive is shared
under the name CDRIVE.

If you open the database on ROSS, the linked tables can point to
C:\data\otherfolder\linkeddata.mdb

But if you're working on another another machine (let's call it
"CROMARTY"), C: refers to SHAW's C drive, and you have to map ROSS's
shared C drive - for which the UNC name is \\ROSS\CDRIVE to some other
letter (e.g. F. This means that when someone opens the database on
CROMARTY, the linked tables will need to point to
F:\data\otherfolder\linkeddata.mdb

And if there's another machine ("FIFE") on which \\ROSS\CDRIVE is mapped
to E: instead of F:, the linked tables will need to point to
E:\data\otherfolder\linkeddata.mdb

On the other hand, if you point the linked tables at
\\ROSS\CDRIVE\data\otherfolder\linkeddata.mdb
they will work on all machines without alteration.

John,
I have looked at our peer-to-peer network which uses 98 2nd Ed. It is set-up
to share the C-drive on each computer and not just specific files. Is this
the problem? Where would we use your example of a naming convention to share
the database without using drive letters? I have read Microsoft's Support on
setting up a network using 98 but did not come across any information that
would help setup sharing a file without using a drive letter.

I'll practice splitting a copy of our database to see if I run into any
problems.

Thanks again,
Donna

On Thu, 28 Aug 2003 15:03:31 -0500, "DSmith"

John,
Our network is peer to peer. Would using the UNC still be true?

Yes.

What does UNC stand for?

Uniform, or universal, naming convention, or some such.

I have thought about splitting the database but would like to
read more on the pros and cons. Although, our database is large it

does
what

we need it to do without any corruption or problems in 9 years. I'd

hate
to

cause any due to ignorance on my part.

Splitting tends to prevent corruption and other problems with multi-user
databases ... so if you're not having any problems the case for
splitting isn't quite so strong. I'd still be inclined to do it as a
precaution, especially if the database is large and precious.


John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.

John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.