VBA for Path of Current MDB

[undrline via AccessMonster.com]

I want to relink tables based on the current path of the file (second mdb
will always be in the same directory as the first). I have the module all
set up for relinking. I just need to know how to get at the current path.
Does Access know what directory the current file is located in? How do I get
at that in VBA? Will it return the UNC path or the logical path, or can I
choose?

Thanks.

 

[Patricio]

I want to relink tables based on the current path of the file (second mdb
will always be in the same directory as the first). I have the module all
set up for relinking. I just need to know how to get at the current path.
Does Access know what directory the current file is located in? How do I get
at that in VBA? Will it return the UNC path or the logical path, or can I
choose?

Thanks.

Sub PathDbInfo()

dbName = "YourDataBaseName.mdb"
Set MBase = CurrentDb
PathInfo = CurrentDb.Name
PathInfo = Mid(PathInfo, 1, Len(dbName) - 1)


End Sub

 

[Dirk Goldgar]

I want to relink tables based on the current path of the file (second mdb
will always be in the same directory as the first). I have the module all
set up for relinking. I just need to know how to get at the current path.
Does Access know what directory the current file is located in? How do I
get
at that in VBA? Will it return the UNC path or the logical path, or can I
choose?

In Access 2000 and later, CurrentProject.Path gives the folder path. If
that's a network path, I don't know for sure whether it will be the UNC path
or not. However, you really should not be running the front-end database
from a network share, as that is more corruption-prone.

 

[undrline via AccessMonster.com]

This didn't work so well, because of the string handling. I bet it could've
worked if I played with it more. Didn't test it on a UNC path.

I want to relink tables based on the current path of the file (second mdb
will always be in the same directory as the first). I have the module all

[quoted text clipped - 4 lines]

Thanks.

Sub PathDbInfo()

dbName = "YourDataBaseName.mdb"
Set MBase = CurrentDb
PathInfo = CurrentDb.Name
PathInfo = Mid(PathInfo, 1, Len(dbName) - 1)

End Sub

 

[undrline via AccessMonster.com]

The only databases that we'd be dealing with would be 2000 or later, so
CurrentProject.Path worked great.

Haven't tried it on a network location to find my answer about the UNC path.
It's not really your standard front-end, back-end setup, though. It's sort
of a front-end, but it only contains queries. It should only be used after
copied locally, but I don't need someone accidentally crashing it because
they opened it on the network and I didn't allow for the possibility in the
code. I seem to recall having issues with Access linked tables and UNC paths.
In an environment where logical drive letters are sometimes automatically
assigned or can be reassigned purposely, it makes life more difficult not to
be able to use the absolute path. This should give me the flexibility I need
in any case.

Anyhow, thank you both for chipping in with good answers, and responding so
quickly.

I want to relink tables based on the current path of the file (second mdb
will always be in the same directory as the first). I have the module all

[quoted text clipped - 3 lines]

at that in VBA? Will it return the UNC path or the logical path, or can I
choose?

In Access 2000 and later, CurrentProject.Path gives the folder path. If
that's a network path, I don't know for sure whether it will be the UNC path
or not. However, you really should not be running the front-end database
from a network share, as that is more corruption-prone.

 

[Tony Toews [MVP]]

However, you really should not be running the front-end database
from a network share, as that is more corruption-prone.

Sharing the FE on a network is very much corruption prone. But
running your own copy of the FE from the network might be more
corruption prone on the FE but very, very slightly. A client is
running the FE from the network server on a Terminal Server/Citrix
setup and I don't recall any FEs getting corrupted in several years.
About 10-15 users daily were in this system.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Dirk Goldgar]

Sharing the FE on a network is very much corruption prone. But
running your own copy of the FE from the network might be more
corruption prone on the FE but very, very slightly. A client is
running the FE from the network server on a Terminal Server/Citrix
setup and I don't recall any FEs getting corrupted in several years.
About 10-15 users daily were in this system.

Sure, Tony, running via terminal services is no more corruption-prone, but
then Access isn't really running across the network.

 

[Tony Toews [MVP]]

Sure, Tony, running via terminal services is no more corruption-prone, but
then Access isn't really running across the network.

If each users FE resides on the file server rather than the Terminal
Server/Citrix system then yes you are running the FE over the network.
In my experience IT departments don't want to copy the users FE to the
TS/Citrix system. Now chances are both are physically next to each
other, very good hardware and lots of UPSs so the chances of a problem
are even less.

Although it has happened. One of the four Citrix servers at a client
was causing occasional corruptions.

Tony


--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[david]

Returns the UNC path, logical path, short path, long path, whatever,
depending on how it was opened. In some obscure circumstances
you may even loose the path, and have only the filename, but I've never
seen that.

You can use Windows API calls to try to work out a UNC path, but
why do that? Let the user decide what kind of path to use.

(david)