>>>The thing to keep in mind, in my opinion, is that once you are addressing
disk space other than local drives, drive letters are at best a handy
shorthand - the more accurate and (hopefully) unchanging notation would be
the UNC notation.
>
>>Sorry, I'll have to take the other side on this one. The reason being that
we just changed server operating system versions. Among the things that
changed were the volume name of the servers, which changed the way they're
addressed. Had my applications not been setup to look for the drive letter
path combination, there would have been many hours spent re-writing and
debugging. As it is, I've had to do nothing to deal with the change over.
>
>There are several solutions that could work here:
>
>a) Pathing based on variable drive letter. In this case, the application
needs to learn the relevant drive letter - I'd judge this the least
effective.
>
>b) Pathing based on absolute drive letter. Better, but you essentially
marry that drive letter to that application.
>
>c) Relative pathing - place application on server. Probably the most
flexible, since no letter would be required at all - any good reasons not to
do this?
>
I can think of several. The most obvious one is the need for access to >1
share for the application's data. Changing the current working directory
via CD to a target UNC and referencing things relative to the CWD is great
so long as everything can be accessed from that share.
Pathing based on a drive letter, absolute or dynamic, may be easiest. If a
reference to the UNC of the base share (in the case of NetWare, the
\\server\volume or \\server\volume\extendedpath, or in the case of
Microsoft, the \\machinename\sharename) can be grabbed from a configuration
file, it can be mapped at runtime to the share using WNetddConnection:
DECLARE INTEGER WNetAddConnection IN Win32API ;
STRING cRemoteUNC, ;
STRING cPassword, ;
STRING cLocalDrive
* go to some table, INI file or Registry Key, and retrieve the UNC,
* an optional password, and the drive letter to assign
cUNCToMap =
cPassword =
cDriveLetterToAssign =
* if you've got code to use dynamic drive letters, you can find the last
unassigned drive
* letter by setting cDriveLetterToAssign to the null string, and then:
DECLARE INTEGER GetDriveType IN Win32API ;
STRING @cLocalPath
IF EMPTY(cDriveLetterToAssign)
*Find the last free drive letter
LOCAL cStr, nCtr
#DEFINE cnBaseLetter ASC('A')
FOR nCtr = 25 TO 3 STEP -1
* I don't check A:-C;: because they're reserved in some Win95
versions
cStr = CHR(cnBaseLetter + nCtr) + ':'
IF GetDriveType(cStr) < 2
cDriveLetterToAssign = cStr
EXIT
ENDIF
ENDFOR
ENDIF
IF ! EMPTY(cDriveLetterToAssign)
*We have a drive letter to assign, either fixed or as determined
dynamically
IF WNetAddConnection( cUNCToMap, cPassword, cDriveLetterToAssign) = 0
*Drive letter mapping worked
ELSE
*Drive letter mapping failed
ENDIF
ELSE
*No drive letter found to assign
ENDIF
BTW, WNetAddConnection() will allow you to map local referenced UNCs to
drive letters without changing code. This works in both Win95 and WinNT;
no futzing with external code to use Novell's MAP for NetWare server access,
Microsoft Networkings NET USE for MSNetwork shares, or the annoying and
dangerous SUBST for your local machine from a batch file before starting the
app, or using RUN inside an application.
>d) Direct UNC (addressing volume) - very clean, only problem occurs if
volume names are changed. The argument here would be - how often do you
change (as opposed to add) volume names?
>
Microsoft shares are a bit easier to maintain - as long as the machine name
remains constant, you can move share names around to different disk
partitions/directories pretty much at will. Both are affected by changes in
what machine holds the data.
>e) Mapped UNC (where UNC is acually resolved by a intermediary process) - a
bit complex, but near bulletproof - this would resolve the changing volume
name problem. However, if you're running a system this size, wouldn't you be
using SQL Server?
>
See above. Since this can work with virtually -any- environment (local
machine data, peer-to-peer networks, or virtually all server networks)
without much more than the code shown above, this is my preferred method.
You can also remap drive letter assignments on the fly (assuming no open
files on the drive being remapped and a full FLUSH being done before the
remap using WNetAddConnection)using the above, so you can shift between data
sets on different shares at runtime without shutting down and restarting the
app with different external drive assignments.
Attachment Converted: Edward M Rauh.vcf
