Not every user is computer saavy and will know how
to map drives on their own or even know what a UNC is and how to
enter into an explorer window.
That's because you've been providing them with mapped drives!
I provide support and Access programming to small businesses. My
first Access client to get an NT server was back in 1998. I knew
about networking already from working in a few other environments,
and knew how UNC worked. I was not originally their server admin,
but I was responsible for all their workstations. I set them up with
appropriate shortcuts on the desktop and trained them how to
navigate Network Neighborhood (this was pre-Windows 2000, which
introduced "My Network Places"). They had not difficulty navigating
this way at all.
But, one important thing:
When they got the server, we sat down and had several meetings to
design the structure of how data would be stored on the file server
and what user groups and security levels would be implemented. The
key is to have a a half dozen distince top-level shares, rather than
sharing the root of a data folder on the server. It's much easier to
get to your data if you have, say Administrative, UserData,
PublicData, ClientData, and so forth as your top-level shares,
instead of having to navigate to the root of drive and then drill
down to those folders.
Now, the organization of the data on the file server's hard drive
was completely different than what was presented to the users. The
key point is that you organize the hard drive for security, backup
and system administration purposes, and then design your shares to
reflect user needs for access.
Most shops I've been in have taken no care at all in designing the
shares presented to the users. There's also the problem of Windows
Server presenting a whole bunch of visible shares that are not for
end users (such as Exchange and so forth). That problem has
increased since the days of NT 4 Server, so it does make things
harder in terms of the top-level server view being crowded with a
bunch of shares that are not of interest to the end users.
The key point was that we organized the server and shares to reflect
the way the users wanted to have their work organized, and then
trained them on how to use UNC paths and how to navigate the server
and its shares in Windows Explorer. After only a few weeks, the
users all understood the system and had no difficulties whatsoever.
And we didn't have to worry about maintaining any logon scripts.
I have tried both ways to link tables together and both have
worked as designed. Although the situation of the VBA code being
deleted sounds rare, based upon several postings, it does indeed
happen. And from our standpoint at work, it is related to the
attempt of opening the database prior to the mapping script being
completed. Since users are now using a script to check for the
existence of the mapped drives and then executes Access to open
the database, we have not had any problems. I don't think this is
100% foolproof.
That sounds to me like a network configuration error. The logon
script that maps the drives should be executing long before the
users have any possibility of loading any applications. At least, in
all the environments I've worked in (which is pretty extensive now,
more than 10 years after my first heavy-duty Windows networking
experience), the logon scripts run before the desktop even populates
with its shortcuts. And they run just after the TaskBar and start
menu button appear, but before the start menu actually responds to
mouse clicks.
Something sounds odd there to me.
But, at least you've come up with a solution. I can't quite figure
out *why* it would be the solution, but the longer I'm in this
business the more I realize that the systems we work with are so
complex that more and more I am willing to try "voodoo"
troubleshooting, i.e., doing things that logically don't have any
connection to the problem, but that sometimes solve the problem
anyway.
I'm not yet sacrificing chickens and sprinkling their blood over the
servers, but I'm on track in that direction!
