This is a true tale of a simple task gone awry. A file transfer that eventually involved multiple IT professionals, all kinds of hardware, site visits and was finally resolved with a screwdriver. The lesson learned: be agile and alert, and keep your toolbox handy.
The story begins with a phoned-in user service request: "Please transfer a database file from an old machine to a new workstation."
"No problem. We will connect remotely to your old machine. Click OK when you see our permission access window." The user did not see the prompt. "Try again." The user still did not see the prompt.
That's when we realised the user was really remote. We have a contract with a local prison to supply clinical care including routine computer support. The prison had its own very private network. No outside access. Our sophisticated remote administration tools suddenly became ineffective.
A site visit was planned. Paperwork followed. Travel vouchers. We did not know what to expect, so we contacted the prison's lone tech-support person. And I got a shock.
The user machine was a very old Dell box running Windows 98. The hardware was encrusted with a decade of dust and grime. The operating system was the original version and had never been updated with service packs or security patches. The data file was created using Microsoft Access 97, long since outmoded. (Seasoned database administrators know that Access 97 databases must be converted before they are fully functional in a contemporary Access environment. The conversion is irrevocable.)
And then came another challenge: Neither the computer nor the database had ever been backed up, and the production database had never been documented. The developer took the specs with him when he left. To make matters worse, he had "protected" the user by judiciously applying the Hide feature so the inner workings were not visible.
We did not know how the database worked. We could not see how the database worked. We only had the original copy of the database to work with. If our procedures corrupted the data in any way, then we would be held liable.
Now we were annoyed.
Then came the real challenge. The machine room had no network ports or wireless access. There was no Internet access, and the machines were not networked to each other. We could not transfer the file by e-mail or FTP or send the file to an intermediate server.
The 'sneakernet' approach
Move the machines to a networked area? The old machine lacked a network interface card. Install an NIC and then move the device? No one had network hardware of that model vintage.
Back up the file to a floppy disk? The file was too big. Copy the file to a flash drive? The ancient operating system would not detect it. Burn the file to CD? The machine did not have a burner. Install an external CD burner? The operating system would not recognise the drivers. (If we had Internet access, then we could search for archival drivers, but that was not an option.) Install an external Zip drive offered to us by a clinician? The install produced Windows system errors.
Now we were very annoyed.
The Network Approach
Create a makeshift peer to peer network? All our available cables were incompatible. Use link software for a master and slave?
The software would not load.
The database approach
Break up the relational database into smaller tables, copy each to a floppy and then reassemble them on the new workstation? The database was too complex. Export the data to a spreadsheet and then reconstruct it? Customised interfaces and reports could be lost.
Now we were really annoyed.
The screwdriver approachThink. This data transfer had so far defied our high-tech tools and trouble-shooters. Back to basics.
I took my screwdriver and loosened the external box connectors held together by a decade of dust. Like a surgeon, I slowly exposed the critical components. A metal guard protected the hard drive. Ever so gently, the thin metal guard was teased out of the way. The drive itself was packed into a small confined space. It took several minutes to remove the power cable and ribbon connector. I slowly extricated the disk drive from its seating. (Clearly, the vendor did not want this model to be easily serviced by a user.)
The new machine was a modern workstation with an internal CD reader/writer. I opened it and disconnected the CD cables. I found a small piece of cardboard and stuffed it into an open cavity. The old hard drive was connected to the former CD cables and now rested comfortably on the cardboard, preventing any metal-to-metal electrical interference.
The new machine recognised the old drive as its secondary drive! Now at last we could transfer, backup copy and convert.
Sometimes, we forget the limitations of our technology. A practical experience such as this returns the manager, technician and network analyst back to basics. Sometimes, it takes low tech to do the job and make the user happy.
Lee Ratzan is a systems analyst at a health care agency in New Jersey and teaches technology at Rutgers University.