Crystal Reports Tools: Improve Performance While Saving Time and Money
  Resources  
Best sellers:
cView
Report Analyzer
cViewSERVER
 ReCrystallize
 

Buy Crystal Reports

Articles:
 Administration
Advanced
Basic
 Crystal eNL
Database
Financial
Problems Solved

 Books:
CR Books
Database Books
Developer Books
 
Tools:
All CR Tools
CR Analyzers
CR Bestsellers
DataBase Tools
CR Graphics
International
CR Mail UFLs
ReCrystallizePro
CR Schedulers
CR UFLs
CR Viewers


Add'l:
About us
Contact Us
cViewSUITE Ppt
Support
CR trial
 

Crystal Reports
on Steroids

IT Basics: Mapped Drives

Use 'em or lose 'em? The jury is in.

Many of our support issues arise from IT practices that are not recommended. The use of mapped drives is, today, one of those practices (in almost every case).

Not a bad idea--in the past

Mapped drives made sense in the days when client machines ran on DOS, the maximum hard drive size was 512MB, and hardly anyone had a drive larger than 60MB because of the sheer cost. From that era, we have inherited legacy applications and, in many cases, a legacy mindset, in which Mapped Drives have a positive role instead of a negative one.

Drive space is not a reason for using Mapped Drives. As this article is being written in early 2008, drives of 1TB are easily affordable.

Back when systems ran on "Win DOS"--that is, the DOS kernel version of Windows such as Windows 3.x and Windows 9X, mapped drives helped users in several ways, because they could save files on the network vs. on a machine burdened by the DOS kernel.

With the DOS kernel, the OS can read only one drive at a time. With the NT kernel, the OS can read two drives simultaneously. Corporate computers originally ran on "Win DOS" so drive letters were already determined by the time a real OS came along for the office environment.

Data drive needed

Instead of Drive D for data and Drive C for apps and OS, the typical corporate computer saves data, apps, and OS on Drive C. This means if the OS needs to be reinstalled, the data are lost. Laptops have inherited this single-drive problem, though partitioning helps limit the damage. But again, you're up against legacy drive labels (which is why we can't use A or B today).

The D drive, in most environments, simply isn't available for a separate data drive in the client machine. That issue helped drive the practice of saving critical files over the network to a server that gets backed up routinely and properly maintained. This would make sense in most cases, even if you had a separate data drive. Without one, it's pretty much imperative or you risk total data loss in the event of even a minor OS glitch.

There was also the idea that you could presumably gain a speed advantage by having the application run on the user's clunky client while pulling data from the network (back in those days, the data flow was less also).

 
None of this even begins to touch the issue of work groups. How can six people update a CAD drawing, Excel spreadsheet, Access database, Photoshop file, or other document they are collectively working on? Copying to removable media and walking from client to client with that file gets a bit tedious after a while. And there has always been a problem with getting users to respect the idea of a "Master copy." Having specific data files stored on a central (shared) drive solves a slew of problems. This, also drove the use of mapped drives.

The fly in the ointment is that, to get access to the shared network drive, the user has to successfully locate the share. Few users feel comfortable typing in any kind of drive path (which was also a problem in command prompt DOS environments). One reason admins went to mapped drives was so that users didn't have to type in the correct UNC path for the share. There are other, better solutions today.

If you set up a mapped drive, users could use My Network Places or Windows Explorer to open a folder or file on the mapped drive. With these tools, the drive appears as just another folder on their system. The user could save files to a drive assigned to that user.

Not all roses

If you use mapped drives and the underlying share isn't available, the client machines will grind away during bootup trying to find that share. And it can be missing for all kinds of reasons. So your network is down and a user tries to boot up. XP and Vista can't tell that the share is actually down--they spend considerable time looking for it.

This same issue can cause the client machine to simply hang. Windows has a "drive missing" event and can't decide whether to sh-- or go blind. The user, meanwhile, stares at the hourglass in frustration. If you've ever heard "synchronized swearing" in a cubicle farm environment, this was probably the cause. Everyone's computer locked up at the same time. While the blue haze of "creative vocabulary" is still wafting past you, the next thing you hear is a chorus of Windows shutdown music as 100 users simultaneously reboot and before heading to the break room.

Can you say, "productivity killer?"

Another problem is users set up their apps to save to, say, their projects folder on Drive Y. You change the share structure (presumably for good reason), and the next thing you know users flood the system with support calls. Network applications may also be compromised, even if you don't have user problems (which, rest assured, you will).

Yet another problem with mapped drives is they create conflicts with the security settings on Internet Explorer. Do you really want to have the work of setting up zones properly on all client machines?

Don't go there

There's really no compelling reason to use mapped drives, these days. If you have an application with workgroup functionality, it should have other ways of making a file accessible to the users. If not, contact the vendor. In some situations, you will simply be stuck with a product tied to the use of mapped drives, unless you can get approval to change to something else. And that can open a whole can of worms.

Many IT people are content to let a sleeping dog lie, rather than go through a major change just to eliminate mapped drives. Here are a couple of examples:

  1. If you use ODBC to set up an Access database on a remote machine, you need to map a drive to that machine/share. The ODBC driver expects a device path to the MDB file. It doesn't recognize UNC paths. A developer might program an application to always look for the data on J:accounts.mdb, as that makes life a lot easier. But if someone else needs a J: drive for their application, everything falls apart. An ODBC connection to DSN=Accounts will work for all sites, and just requires ODBC to be set up using whatever spare drive is available to the MDB on the server.
     
  2. Btrieve (now called Pervasive SQL) insists you use a mapped drive to the data and the btrieve drivers must have them. I don't know why developers still work with that one as performance is a real drag when volumes get up a little bit. Totally doesn't understand the reason for client server rather than a file based architecture.

But in most cases, you can get rid of mapped drives with little (if any) downside. If you have an Active Directory network, you have a good alternative to mapped drives. There are other alternatives, as well. You may give up the convenience of "My Network Places" but that's a small price to pay for system hangs, bootup delays, "lost" folders, broken connections, and other issues that invariably arise with the use of mapped drives.

If you are setting up a new system, don't go to Mapped Drives. You'll be glad you didn't. And so will your software vendors' support staff.

 

This article is copyrighted by Crystalkeen, Mindconnection, and Chelsea Technologies Ltd. It may be freely copied and distributed as long as the original copyright is displayed and no modifications are made to this material. Extracts are permitted. The names Crystal Reports and Seagate Info are trademarks owned by Business Objects.