Hyperlinks and UNC

  • Thread starter Thread starter BruceM
  • Start date Start date
B

BruceM

I seem to remember that when inserting a hyperlink into a field in Access
2000, it was stored in UNC format, no matter if the user navigated through
the network or via mapped drive letters. In Access 2003 the hyperlink is
stored as a mapped as a drive letter if the user navigated to the file by
that route. Do I recall correctly about Access 2000?
 
No you do not remember correctly. If this was the case it was because the db
had been setup to convert it to UNC or because the user input a UNC path.
Either way you need to code your db to convert drive letter to UNC format.
For this look at

http://www.mvps.org/access/api/api0003.htm

you use the fGetUNCPath to convert drive letter to UNC format before coming
the path entered/selected by your users.
 
Thanks for the reply. I am inserting a hyperlink by setting the focus to a
control bound to a hyperlink field, then using:
DoCmd.RunCommand acCmdInsertHyperlink
in a command button Click event.
Unfortunately I do not know what to do with the code after I have pasted it
into a module. I understand that I use the custom function fGetUNCPath, but
where and how I would not be able to figure out without extended study,
assuming I could figure it out at all.
It's too bad Microsoft insists on hanging onto the anachronistic drive
letter system. It is all but worthless in a network environment, unless
there is rigid administrative control over drive letter usage.
 
Interesting how differently people look at things.

We couldn't exist in our environment if there weren't mapped drive letters.
Each user automatically has particular drive letters mapped on logon. That
means we know every user has specific data folders on the I: drive and
programs on the J: drive (although they won't necessarily be mapped to the
same servers). Needing to know that user A's data is on
\\server1\datafolders while user B's data is on \\server3\data would be
horrible.

And while we do have "rigid administrative control over drive letter usage",
it's only for 4 particular drive letters.
 
My point about "rigid administrative control" is that unless all users have
mapped a particular drive to the same drive letter, UNC is the only way to
manage links to network folders in the circumstance where everybody needs
the link to point to the same specific location. It is frustrating that the
route to link to a file on a network folder often involves drilling down
through the entire network hierarchy. When I click on My Network Places,
some of the drives are identified by name (Administration, Shared, etc.), so
that I don't need to drill down through the network name and the server name
to get to them, but others don't show up on the "quick pick" list. I can't
discover the reason for this. It will probably take considerable research
before I can figure out how to use the functions in the link to translate
the drive letter to a UNC path. At that, I cannot be sure my efforts will
lead to a workable solution.
In my situation, drive letters have no meaning from one workstation to
another except by coincidence. I cannot change that, and am left with few
alternatives unless I can figure out how to get the code to work.
 
And while we do have "rigid administrative control over drive
letter usage", it's only for 4 particular drive letters.
Click to expand...

Have you no experience with UNIX file systems and the way they serve
up shares? It's much easier to deal with than either UNC or mapped
drive letters.

I'm very much against mapped drive letters, too. I see it as an
artifact of the days when people used Novell servers, especially the
inefficient and stupid way in which drive letters are mapped.

In 1998 I set up a client with an NT 4 server and new workstations
in a new office and we didn't map a single drive letter. We
carefully planned the server share hierarchy, and installed
shortcuts to the top-level shares on all the desktops. We also
taught the users how to navigate shares and Network Neighborhood.
They all found it very easy, and never looked back.

Of course, it was a single-server environment. In a multi-server
environment, I can see how the mapped drive letters could make
certain things easier.
 
David W. Fenton said:
Have you no experience with UNIX file systems and the way they serve
up shares? It's much easier to deal with than either UNC or mapped
drive letters.

I'm very much against mapped drive letters, too. I see it as an
artifact of the days when people used Novell servers, especially the
inefficient and stupid way in which drive letters are mapped.

In 1998 I set up a client with an NT 4 server and new workstations
in a new office and we didn't map a single drive letter. We
carefully planned the server share hierarchy, and installed
shortcuts to the top-level shares on all the desktops. We also
taught the users how to navigate shares and Network Neighborhood.
They all found it very easy, and never looked back.

Of course, it was a single-server environment. In a multi-server
environment, I can see how the mapped drive letters could make
certain things easier.
Click to expand...

I am talking hundreds of servers in dozens of locations world-wide.
 
I am talking hundreds of servers in dozens of locations
world-wide.
Click to expand...

That's really not even close to the environment that most of us work
in.

I am embarrassed that Windows doesn't offer anything better than
drive letters for this kind of thing.
 
I would like to see a way to translate a drive letter to UNC, maybe showing
the drive letter to the user, but storing the UNC path, rather like the way
hyperlink text can by whatever is wanted, while the actual link is used
behind the scenes. It is apparently possible to translate drive letter to
UNC, but the method for doing so does not seem to be documented (at least
not on the MVP site where the code is posted -
http://www.mvps.org/access/api/api0003.htm). Perhaps somebody with more
experience than I would know what to do with the code, but I'm stuck with
trying to train users to go drill down through the network. They won't. I
already know that.
 
Are you saying that the fGetUNCPath function on that page (which uses the
WNetGetConnectionAPI call) doesn't work for you?

I'm sure I've used it successfully in the path. It should be as simple as
fGetUNCPath("E")

Take a look, too, at Randy Birch's example at
http://vbnet.mvps.org/code/network/uncfrommappeddrive.htm

Unfortunately, I'm at home recuperating from surgery at the moment, so I
can't easily test it.

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


BruceM said:
I would like to see a way to translate a drive letter to UNC, maybe showing
the drive letter to the user, but storing the UNC path, rather like the way
hyperlink text can by whatever is wanted, while the actual link is used
behind the scenes. It is apparently possible to translate drive letter to
UNC, but the method for doing so does not seem to be documented (at least
not on the MVP site where the code is posted -
http://www.mvps.org/access/api/api0003.htm). Perhaps somebody with more
experience than I would know what to do with the code, but I'm stuck with
trying to train users to go drill down through the network. They won't. I
already know that.
Click to expand...
 
Sorry, meant to say "I'm sure I've used it successfully in the past."

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)


Douglas J. Steele said:
Are you saying that the fGetUNCPath function on that page (which uses the
WNetGetConnectionAPI call) doesn't work for you?

I'm sure I've used it successfully in the path. It should be as simple as
fGetUNCPath("E")

Take a look, too, at Randy Birch's example at
http://vbnet.mvps.org/code/network/uncfrommappeddrive.htm

Unfortunately, I'm at home recuperating from surgery at the moment, so I
can't easily test it.
Click to expand...
 
Douglas J. Steele said:
Are you saying that the fGetUNCPath function on that page (which uses the
WNetGetConnectionAPI call) doesn't work for you?
Click to expand...

Thnaks for the reply. I'm saying that I don't know how to find out if it
works or not. The code assumes a level of understanding I do not have.
Since there is little documentation accompanying it, I cannot discover how
to use it.
I'm sure I've used it successfully in the path. It should be as simple as
fGetUNCPath("E")
Click to expand...

For lack of a better idea, I tried ?fGetUNCPath("E") and ?=fGetUNCPath("E")
in the immediate window, but nothing happened except for error messages
saying in one way or the other that more was expected.
Take a look, too, at Randy Birch's example at
http://vbnet.mvps.org/code/network/uncfrommappeddrive.htm
Click to expand...

Again, I don't know how to make it work. In both code examples the code is
apparently expected to work on a string that represents the drive letter
path, but I have not yet discovered how to plug that string into the
function. The trouble is that there are functions within functions within
functions, with constants and variables interspersed. In Randy's example I
would need to start with the command button's Click event, analyzing the
functions that are used there in an attempt to discover their basis, and
likewise working backward from there. Unfortunately I cannot take the time
that would be needed to sort out all of that. I don't doubt that it is all
quite clear to an experienced developer, but I would have to devote at least
several days I do not have to understanding how to make it work. I probably
need to accept for now that for me this is a problem with no solution.
Unfortunately, I'm at home recuperating from surgery at the moment, so I
can't easily test it.
Click to expand...

Get well soon. I appreciate your taking the time to reply.
 
Because fGetUNCPath is declared as a Private function, you can't invoke it
from the Immediate Window. Change

Private Function fGetUNCPath

to

Function fGetUNCPath (or Public Function fGetUNCPath)

What do you see when you run sListAllDrives in the Immediate Window? What
does it show after Network Drive : ? Whatever's there is what you'd plug
into the call to fGetUNCPath
 
sListAllDrives does indeed show a listing of all drives, including the
network path, something like this:
Network drive : P:\
UNC Path : \\ServerName\Public

However, fGetUNCPath gives me a "Bad Device" error if I try something like:
fGetUNCPath("E") where E is a mapped drive. I changed all of the functions
and constants to Public, but the error still occurred.

I think the difficulty is with:
Public Declare Function WNetGetConnection Lib "mpr.dll" Alias _
"WNetGetConnectionA" (ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, cbRemoteName As Long) As Long

I changed "Private" to "Public", but otherwise the code is untouched. I
really have no idea what is going on with "Public Declare Function" (as
opposed to "Public Function"), or what ByVal is all about. In some way
lpszLocalName, lpszRemoteName, and cbRemoteName are acquiring values, which
are then getting used in WNetGetConnectionA (or WNetGetConnection) when it
is used in fGetUNCPath (I think), but once again I am lost.
 
Back
Top