The Network Technician argues that the share name will change the moment a new drive is installed replacing the current drive and the share name will differ.
Shares can be moved. But more important, if the share is moved but the new meaning is correctly updated and published, YOU WON'T KNOW THE DIFFERENCE if you use the \\server\share\sub-path\file.type mapping, which is UNC style.
If your techie person says you cannot rely on the share name then you need to FIRE that useless S.O.B. before he screws you to tears because he clearly knows NOTHING about proper mutli-machine network management. Share names are what you use to PREVENT disruption by internal resource changes. You update and publish the new name and never know that the drive was just changed from a 256 Gb disk to a 2 TB disk. You just keep on using it but it suddenly seems bigger.
Technically, yes... It is possible and even likely that replacing a drive will cause the physical path to change. But if your tables stored fields based on the drive:\path\name.type info and the drive was changed out, the stored data would have to be changed too, because the drive letter is a LOCAL item.
If you carefully reverse-engineered Windows, or (better still) read a book on Windows Internals, you would find that the drive letter table is a DATA STRUCTURE: a list of POINTERS to devices that can include ANYTHING - technically, including serial ports if you wanted to map it that way (though I wouldn't do that). It is just a text table of 26 slots where you can put 26 "aliases" for the 26 letters. Technically, the letters are the aliases, but you get the idea.
When you use
X:, that merely picks up the contents of slot
X in the table and appends whatever was to the right of the colon. So... if drive X: is mapped to "\\SEAGATE-DP4\06Quotes" then ELIMINATE THE MIDDLEMAN. Just use "\\SEAGATE-DP4\06Quotes\rest-of-path" directly. HINT: If the drive gets replaced bad enough that the Share info changed, the alias underlying the X: entry is wrong, too!
In fact, I'm going to be brutal about it. What you described is a potentially really bad design choice. You should NEVER EVER use drive-letter mapping for data that references files from inside a database. But now the good news. If you had room for the drive:\path\name.type mapping, you have room for UNC mapping, since they usually take the same amount of space.
We had a situation with the U.S. Navy where I ran an Access database that was potentially used by about 40-50 users (not necessarily all at once). But 40 to 50 users, each with their own laptop or desktop (could not predict which) and 40 to 50 different combinations of apps that each one ran, each app having its own unique drive letter requirements. The drive letter conflicts made it IMPOSSIBLE to use a single drive letter for everyone. So my
only solution was UNC mapping for all database FE/BE links AND for all files referenced from the tables and modules from within the database files. Once I implemented that, I never again had a drive-letter problem.
If your current design originates from advice from your network manager, it is time for a come-to-Jesus meeting with that person. I don't care if you show that person this post. I'll answer questions. My qualifications include 28 1/2 years of experience with a U.S. Navy network with over 1200 servers and 80+ major projects including the system that ran the manpower management decisions for the entire U.S. Navy. Trust me when I say that we got that working right in the environment I described. If it meets U.S. Navy standards, it ain't wrong. (Complex? Maybe. Wrong? No.)
0IMG_20180817_135033.jpg
0IMG_20180817_132257.jpg
