Jurgen Welz
jwelz at hotmail.com
Thu Jul 19 08:42:36 CDT 2007
An anomoly I've recently run into has been an inconsistency in mapping of
several of our drives in a Remote Desktop environment where the server
environment is Win2K3 Server.
When a user of mine clicks a record's explore button on a form, the
application checks for the existence of the record's target folder and
creates it if it doesn't exist. The target path is passed to shellexecute
and a windows explorer window opens to the target path. If the mapping is
good, the path is correct and any existing files or folders are displayed.
If the mapping doesn't exist, the procedure that creates the path creates a
path alright. It is on the correct drive, but it is an 8.3 path. The
explorer window will display the full mapped path at the top of the window.
Users will drag files into this folder to related them to the record. For
example, we may get some pdf specs and some dwg blueprints, or email
correspondence. The users navigate to the record, pop the explorer window
and drag or paste files into the record's folder. But if the mapping is bad
and there are spaces in the file name or parts of the path or file name
exceed 8 characters, there is a problem. If the file name doesn't comply
with the 8.3 or has a space, Explorer will present a user with an error
message and offer to fix the file name. When the file is pasted, it goes
into a locaton with a truncated path and never appears in the explorer
window the user has open into which files are pasted. Bizzare.
If the application creates a file, like an estimate, Word or Excel file, it
will save it in a truncated path. No error is ever returned by the file
system. If my procedure calls MkDir in a loop to
create("S:\GOM\Vancouver\2003\..."), the code will in fact create
S:\GOM\Vancouve\2003\..." truncating Vancouver and never giving an error.
In such a case, the file will be saved in the truncated path and the name
will be truncated, if necessary, but no error message at all is returned
anywhere.
This problem started happening in April 2007. I am told by IT that it has
to do with terminals that allow upload by providing access to local
resources (local usb connected ports). However, this had never been a
problem in the past.
The older versions of the server Windows would report an error in a
situation like this and the 2003 version had been reliable for the 2.5 years
preceeding this April even though we've had access to local resources the
entire time. There must be some service pack to the server windows that
messed up the system. With the older versions of Windows, I could
occasionally enumerate mapped drives and the system would list drives that
were actually disconnected. The only reliable means of verifying a mapped
drive was to run a directory against the mapped drive and see if a '.' was
returned.
For this reason I mentioned in the previous post that I verify existence of
mapped drives. The bizzare thing is that the base path I create is on the
mapped drive and thats where it is created, even if the mapped drive doesn't
exist. The solution was to use the UNC paths, but that was complicated on
the July 1 long weekend when we switched from 2 servers to 5. While most of
the files remain on a single server, all Estimate files need to reside on a
root (C or D) drive of the former 2nd server. Fortunately, copying to the
UNC will place them on an appropriate root drive. As the servers are broken
down on a regional basis, I've had to update my code to work with the
correct server in the situation. Given that all servers are mapped
identically, it would have been easier to stay with the drive mappings, but
reliability concerns have prompted me to consider moving strictly to UNC
paths.
Ciao
Jürgen Welz
Edmonton, Alberta
jwelz at hotmail.com
_________________________________________________________________
Fight Allergies With Live Search
http://search.live.com/results.aspx?q=Remedies+For+Spring+Allergies&mkt=en-ca&FORM=SERNEP