Mcgillivray, Don [IT]
Donald.A.McGillivray at sprint.com
Wed Nov 23 12:41:09 CST 2005
Hello All, I have an Access DB that, among other things, monitors folders on various network drives and moves files between them depending on certain conditions. The system runs 24x7 on a terminal server session. As part of the code that manages all of this, I check for the existence of the attached drives before attempting to perform any processing with them. The test uses the Dir() function and the UNC path to look for a known test file on the target drive. If the file is not found, the drive is presumed to be AWOL and my code attempts to attach to it (using the NetWork object of the Windows Script Host), returning an error if unable to do so. While testing this "check and attach" procedure, I manually disconnected the target drive, and ran the reconnect procedure. The procedure returned no error code, but Windows explorer displayed no evidence of the drive having been attached and assigned a drive letter. Refreshing and killing and restarting Explorer had no effect either. Nonetheless, when I run a Dir() from the immediate window (using the UNC path), the target test file is found. Likewise, FileCopy works against the UNC path. Both functions fail when using the deleted drive letter instead of the UNC path. Looks to me as if the mapping persists as a UNC resource, despite the drive letter having been killed. If I kill the terminal server session and restart it, the attached drive is unavailable both under its UNC path and the drive letter. I guess this is not really a problem if my program can still communicate with the resource via UNC path. It's just a bit disconcerting to not see it mapped to a drive letter in explorer. Anybody have an explanation, or better yet, a method for *really* killing a mapped drive in a terminal session? Thanks! Don McGillivray