What is "dynamic" addressing like \\MyDrive\MyMap\My.mdb

As there are no other reference to this question just Nico's name I am posting a comment as to what I do in getting a path. This helps me and the app when I have multiple users with different mapping letter used to app path.
I usually try to get the path using the
value from
currentdb.name
this gives me the path the database is in. That is how I use dynamic path retrieval.

Using the dynamic addressing as you call it allows you to link to a file that is on a network drive.  It also allows users to access the file even though they have not mapped a drive letter to this network drive, plus you don't have to worry about every user user using the same drive letter.

You can use this in linking tables, but if you have already mapped the network drive to a letter (eg \\MyDrive\MyMap to M) and try to link to My.db the connection will get updated to m:\MyDrive\MyMap\My.db
to fix this disconnect the mapped drive first.

You can use the database from anywhere that has access to the network drive (eg \\MyDrive\MyMap)...

As for using drive letters less that "F", that is your personal preference only as Access does not care what drive the database is linked to.

devtha,


Sorry about not citing the ref, Nico adn I were having an off? discussion and I thought it better to terminate the other ? and spread a few points about on this one. The ? was:

How to ref items in a query from VB

 
 pbryan , your answer is very intriguing.

I don't usually operate on networks so I don't know anything about them, but my current client operates a large network and the application has multiple users who map their computers differently so I've had quite abit of difficulty getting things to work for all users.

I'm using a frontend db with the code and a backend db with the data on a networked drive.  Both db are in the same folder.

Previously, using reg addressing (i.e. F:\FolderName.dbnam.mdb) , when each user signed on the db would relink the frontend to the backend using whatever drive letter the user had mapped his computer to.  Whenever another user mapped to a different drive letter, relinking would occur again and users not mapped to the new drive letter were blown off with errors.

My feeble solution was to disable the auto relinking for drive letters greater than "E" and force all users to map to the same drive.  Although not the best, this works.

For drive letters less than "F" auto relinking is enabled.  Reason, some users copy both dbs off the network and take the data with them on personal computers.

I'm interested in a better addressing solution., but it needs to work with networked and non-networked drives.

Even if there is not a better solution for this environment, explain how to set up the \\my..

Best

Elton

I think my option is better since your both dbs are in the same folder.
Take a look. This will work regardless of what drive the users used to map.

in ALL of my applications I ALWAYS do all my linking to back-end database/s using the UNC convention. (i.e. //<servername>/<directory>/<databasename.mdb> ) to overcome the problem of different users mappings.

I also provide a (standard) routine to check the validity of the "links" at the startup of each application, and if not available (or changed) display a common dialog for the users to define where the back-end is (now). My standard instructions to users is that they "relink" (when required) via the "Network Neighbourhood" icon, but users being as they are I can't guarantee this, so have (now) a common routine which (after they select location and ONLY if done against a drive letter) I convert this drive letter "back" into the standard UNC convention.

Could post it here if interested (away from work today but back tomorrow).

Another comment, you stated that some of your users "take the frontend/backend away on laptops" (off-line). Is that only in "read-only" mode OR how do you ensure that any changes they may have made get back into the "networked" back-end ?

archery,

Please post the Standard UNC conversion routine mentioned above, Thanks.

These dbs are for information only, lots of data in loaded monthly into the dbs and they produce mostly graphs that can be printed, exported, etc.

None of the users can input any data as this is done from a data entry db accessed only by data personnel.  This is also why linking is such a problem.  They are 4 groups (data bases) of data plus a data entry db. Data cannot be shared nor viewed between groups, so is (hopefully) secure via permissions and passwords.

the formats, code, etc. is the same just different data, so the code db is the same in each group db.

Each group has a separate folder with their code and data dbs.  Only the data entry personnel have permissions and passwords that allow entry into more than one db.

Best

Elton

Thanks

Elton