KnowledgeBase (KB) Archived Medarks topic the following kb topic should be treated as legacy information



Download 19.12 Kb.
Date28.01.2017
Size19.12 Kb.
#10168


species360_taglinehorizontal_color

7900 International Drive, Suite 1040

Minneapolis, MN 55425 USA

+1 651 447 5574 · fax: +1 952 853 1280




KnowledgeBase (KB) Archived MedARKS Topic

** THE FOLLOWING KB TOPIC SHOULD BE TREATED AS LEGACY INFORMATION **

** THESE TOPICS ARE NOT ACTIVELY UPDATED BY ISIS **

** THE INFORMATION FOUND IN THESE TOPICS SHOULD BE USED WITH CAUTION **

 

Running MedARKS 5 on a Windows® network (peer to peer networks):


Peer-to-Peer versus Client/Server Networks:

Local Area Networks (LAN's) essentially come in 2 flavors; client/server and peer-to-peer. MedARKS is a multi-user product and can be configured to run on either type of network. However, when networks first started appearing in zoos, it tended to be at the larger institutions where client/server networks predominated. As a result, MedARKS has accumulated much more experience in the client/server network environment and the program was adapted to meet the needs of institutions with these networks. More recently, peer-to-peer networks have gained in popularity, particularly at smaller institutions where the relatively inexpensive peer-to-peer architecture makes this a more affordable networking option. This document discusses the options for running MedARKS on a peer-to-peer network.

On a peer-to-peer network, all the linked computers are essentially equal. It is possible for any networked computer to link to the hard disk of any other computer on the network and access the files on that computer (I will ignore security and access permission issues for this discussion). This process of linking to the hard disk on another computer is called mapping. During the mapping process (connecting to another computer), you assign a drive letter to that mapped drive. So, imagine that you are sitting at computer #1 and the C: drive is your local hard disk. Link across the network to computer #2 and map the hard disk on that computer to your computer as drive D. Now, when you use File Manager (Windows 3®) or Windows Explorer (Windows 95®) to look at the files on drive D, you will actually be retrieving information across the network and you are actually viewing the list of files on the hard disk of computer #2. With a peer-to-peer network, you can be linked to several different computers simultaneously, so you could also map the hard disk of computer #3 to your computer as drive E.

 

In contrast, on a client/server network the computers are not equal. All the workstation computers (the clients) are connected through a single computer (the server). The server is generally not used for direct data entry, but instead, it functions to serve the needs of the workstations. In general, workstations can only access their local drive and the server drive. The process of linking your computer to the server hard drive (or part of the server hard drive) is still called mapping. The mapped drive(s) are also called logical drives (they don't physically exist in your computer, but the network operating software makes your computer behave as if those drives were inside your computer).



There are essentially 2 methods for setting up MedARKS on a peer-to-peer network. Neither is particularly difficult, but some computer knowledge is required. Each method has some advantages and some disadvantages.

 

Common Drive Setup:



It is usually easier to setup and maintain MedARKS on a network when it appears to all computers that the program and files reside on the same drive. On a client/server network, this is fairly simple because the program and data are installed on the server drive, and it is easy to use the same logical drive mapping from the server drive to all the workstations. No matter which workstation you use to access MedARKS, the program thinks it is running on the F drive (or any other valid drive letter) of the workstation.

Running MedARKS with a common drive letter can be more difficult on a peer-to-peer network, where the local hard disk on one workstation is the C drive, but when accessed from another computer, it is the D drive (or some other drive letter). If all the computers have a single hard disk, then the computer where you install MedARKS (computer #1) will access MedARKS on the C drive, but all other computers will have to access MedARKS using a mapped drive (D or higher). MedARKS stores a copy of the drive location information with the program. Once you have the program working on the local drive of computer #1, and then you try to run it from another computer (#2), the program tells that computer to look for MedARKS on the C drive, when in fact, it needs to be looking on the mapped drive. Change the MedARKS drive defaults on computer #2 (so that it looks on the mapped drive) and MedARKS will no longer run on computer #1 (since the program now instructs the computer to use a mapped drive instead of the local hard disk). One obvious solution for a peer-to-peer network is to have MedARKS installed on one machine but only run MedARKS from other computers, allowing you to use the same drive mapping when connecting to the machine with the program. In a sense you have turned the peer-to-peer network into a client/server network for this application. On a large peer-to-peer network this can be a simple but satisfactory solution to the problem. You cannot use MedARKS on one of the computers, but if there are 4 or 5 other computers on the network, this may not be a problem. However, since many peer-to-peer networks consist of only 2 machines, this solution is clearly not acceptable (there is little point in networking the 2 machines if you can still only use the program on 1 machine).

 One solution for a small network relies on partitioning the hard disk of one machine. This is a process whereby a single physical hard disk (C drive) is divided (partitioned), using software, so that it is treated as if it were 2 smaller drives. Now, the local drives for computer #1 are the C and D drives and mapped drives to other computers would start at drive E (or higher). Install MedARKS on the D drive of computer #1. When you want to run MedARKS from another computer on the network, map the D drive of that computer to the D drive of computer #1. MedARKS now runs on the D drive whether you are sitting at computer #1 (running the program on the local drive D) or at any of the other networked computers (running the program on their mapped drive D) and the program has no conflicts. There are a number of software programs on the market that are designed to help you partition a hard disk. With the extremely large hard disks currently available, there is no real disadvantage to dividing the disk into 2 smaller sections. A number of institutions are using this "trick" to run MedARKS on their peer-to-peer networks.

Local Program with Remote Medical Data Files:

The second network configuration can be easier to install (you do not have to partition a drive), but this configuration is more work to maintain. This network installation method takes advantage of the fact that MedARKS stores the medical records data drive information with the program files and not with the medical data files. You can take advantage of this feature to allow you to run the program from the local drive, but have each local program access a common set of medical data files using different remote drive mappings. On many small peer-to-peer networks (2 or 3 linked computers) the benefit of the easier initial setup has been the main consideration and this is the configuration that is often used.

 

The first step is to install the MedARKS program (and make sure it is running correctly) on one computer (computer #1). Now, go to one of the other computers, link across the network to the drive of computer #1 and copy the following 3 folders (and their contents) to the local hard drive:



  • Newmed

  • ISIS.LIB

  • ARKS

Once these folders are copied to the local hard drive, you could now run MedARKS on both computers (the current machine and computer #1). However, both copies of the program are storing records to the local hard drive (two separate sets of data files), so you do not have a networked program. The next step is to get the current computer (computer #2) to store the medical records to the drive of computer #1, so whether you work on computer #1 or computer #2 only a single set of MedARKS data files are being modified.

 

Delete the MedARKS data folder on the local hard drive of computer #2 to prevent the program on computer #2 from storing records locally. To delete the 'data' folder, open the newmed folder, then locate and open the medarks folder inside the newmed folder and finally locate and delete the data folder that is inside the medarks folder. Next, locate the file called med_vars.mem in the \newmed\medarks folder and delete this file. Now start MedARKS on computer #2 using the fmedarks.bat file located on the local hard drive (in the \newmed\medarks folder). The MedARKS program will start the utility to define the system parameters. For the questions regarding the location of the ARKS taxonomic file and the MedARKS program files, specify the local hard drive for the path (should be the default choice). However, for the question regarding the location of the MedARKS data files, change the drive letter for the path to the drive letter that you have mapped to computer #1. Now MedARKS will look for the program files on the local hard disk but will open and use the data files that are on computer #1 (across the network). You can setup computer #2 to automatically create the network connection to computer #1 every time it is started (then MedARKS will always have the data files available on the correctly mapped drive). Repeat this process on any other computers on the network, so that all are running a local copy of the program but editing the data files on computer #1 (remote data files). Once everything is configured properly, you should be able to use MedARKS simultaneously on all the computers and have the complete and up-to-date medical history of any specimen available from every computer.



 

Disadvantages:



  • Much more local hard disk space is used by this installation method (compared to the first method outlined) due to storage of the program files, MedARKS support files, the ARKS files and the FoxPro runtime library files on the local hard disk of each workstation.

  • When a new version of the program is released, the upgrade process must be performed on each workstation to update the local copy of the program.

  • When ARKS files are updated, these updated files need to be copied to the hard disk of each workstation.

written by J. Andrew Teare, DVM
Last update: 13.Sep.1998

 

Contact ISIS Support



Revised 28 January 2017
* Species360 Organizational name change added on 07/18/2016


It is the mission of Species360 to facilitate international collaboration in the collection and sharing of information on animals and their environments for zoos, aquariums and related organizations.


Offices in Minneapolis · Amsterdam · Bogota · New Delhi · Haifa · Istanbul · Buenos Aires




Download 19.12 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page