Jonoke Software Development Inc.
Corporate Info MediFile© Resellers Client Area Contact Us
MediFile© Newsletter Client Reporter Knowledgebase Guides MediFile© Newsletter Videos

10001 & 10002 Errors

The 4D client application puts up error message 10002 and 10001 when communications with the server computer have been lost for more than 2 minutes.

Though not comprehensive for troubleshooting a network problem, this document is a good place for the site administrator to start troubleshooting a network problem. It is written to be less of a technical document and more comprehensible to a wider audience.

Obviously, since MediFile/4th Dimension is a network application, a problem on the network is a serious one. We have seen this problem at various sites and have worked through many of these, assisting people in identifying the problem. From time to time we have been hired to resolve the problem as local networking people did not have the knowledge or experience to resolve the problem. Most network people are used to setting up networks for file-sharing, which is much less intense than database application networking.

This document will try to provide a description of several of the network problems that can cause this error, and how these problems can be discovered and then resolved. This will provide a good foundation for resolving the network problems you are currently having.

Components of the Network

There are several components of a network. Obviously, there is the hardware component, but there is also software, both of which are covered here.

Hardware

Cable — All cable used for MediFile needs to be Category 5 cable. This is an IEEE standard that describes several features about the cable, including the thickness of each strand, the number of twists in the strands per foot, the number of strands, the colour coding of the strands, the pin order of the strands for the connector and the type of connector. All Category 5 cables should be labelled as such on the outside of the cable.

If it is labelled as such, it should meet these standards. Damage to the cable or cable end can cause many problems. These problems can really be anything. The easiest to resolves is when it just does not work at all. But data corruption can arrise when the problem is intermittent (1000x errors etc.).

A cable problem can sometimes be identified with a cable tester. Cable testers are NOT the end all of testing the network, though; We have a $5,000 cable tester and know this.

Additionally, we had a site where the network people certified the network for category 5, and the server was crashing 3 or 4 times a day. The cable in the wall was actually not category 5. Therefore, though the cable tester essentially certified it as solid, there were no twists in the wire, which means that it was not category 5 cable.

The twists in the cable are like shielding for the cable, and are what enables the data to arrive at the other end uncorrupted. When the cable is installed in a commercial setting, it should be run inside conduit. This protects the cable from damage in the future, when renovations occur. A nick in a wire that is barely visible can cause intermittent problems. As a side note, conduit is good as well because it eases the replacement of a cable, or the addition of more cable.

If the connector on the end of the cable runs is broken, the end of the cable will not make consistent contact with the other part of the network. This is usually easily determined. If the cable end does not "click" into the connector, it should be replaced.

Another issue to look for on the cable ends is if all the wires are pushed right to the end of the connector. You can usually see this by looking at the end of the connector. You should see the copper end right up against the connector end.

A final and frequently seen issue with connectors is that the specifications indicate that the plastic cover of the cable should be pushed far enough into the connector that the jacket (cover) is crimped in the connector. This protects the ends of the wire so that they do not get pulled out of the connector when someone works with the cable.

Hubs: Hubs are an important part of the network. There are many brands and qualities of hubs on the market. To some extent, you get what you pay for, and hubs come in several different flavours. At the high end are "managed" hubs, which permit you, Jonoke or a network specialist to control the hub from another computer, to check the problem log etc. Very few people spend the money for such a hub. Most hubs are designed to shut down a specific port if there are problems on that line. Often the only way to get that specific port activated again is to shut the hub down and then turn it back on.

Hubs can be overloaded as well. As a hub works with the data entering and leaving it, it will have a buffer. If the buffer is overloaded, as with all buffers, the data in the buffer will simply be lost. It is very unlikely that this would happen and one of the only ways it would is if a low cost hub (read, small buffer) is used as an uplink hub for other hubs. In other words, instead of being connected to workstations, it is connected to several other hubs. Using a hub in this fashion is not recommended.

Of course, there are several ways that wires can be connected to a hub. If the wiring and connection between hubs is incorrectly done, unexpected and intermittent problems can be created (loop-backs, et al. can occur).

Switches: Switches are really just expensive hubs with some key features that are valuable in a large network. Switches will look just like a hub, except they will say "switch" on them. The key feature of a switch that makes it different from a hub is that it isolates network traffic to the required port. This is key in supporting a large network without slowing down the whole system. At larger sites, the network should be set up so that a smaller hub is used to link 8 – 12 computers to the network. Then this hub has a line running from the uplink port to a port on the switch. The MediFile server and Butlers should be connected to the switch directly. The MediFile Server and MediFile Butlers are usually high traffic items and should be isolated.

Switches come in different flavours. Since switches do traffic management, they have to have a computer built into them. These computers handle the traffic, routing it to the required port. Because of this work, switches have much larger buffers than a hub would have. As with hubs, if the buffer is over-run with data, the data that couldn't fit into the buffer will be lost.

Switches usually have the option of purchasing management software for the switch. The management software can be a very valuable option to purchase if there are network problems. The management software can cost a couple of thousand dollars, so most people do not purchase this option. If your network is having problems though, this can be money well spent.

The management software will have different features depending on what the manufacturer provides. For an Asante Switch, you can determine the features of the switch software by going to their web site, www.asante.com.

Switches are designed to shut down a port where problems are occurring just like a hub does. This is designed this way so that a bad network section will not bring down the whole network. If you do not have the management software, the only way to get a port that has been shut down back up again is to restart the switch. Since the switch is usually the central intersection of the whole network, this will bring the whole network down.

Wireless Networks

Wireless networks work in a similar fashion to a wired network. There are other issues that can cause problems, though. Each vendor of a wireless solution provides different tools for setting up the network, and configuring it. In a general document like this all the different issues that can occur cannot be covered here. You need to know how to set up this wireless network and use the tools provided to trouble shoot the problems.

With a wireless network, it is going to be slower than a wired network. Therefore, do not expect data transfer, window opening with data, etc. to be as fast with the same computer attached to the wired network. Don't under estimate the effect that a slow network has on the operation of a network application like MediFile. The whole program will work more slowly.

Having a slower network will effect your overall satisfaction with the whole system. Waiting a split second for a window to open or waiting 3 seconds may not seem much. But when this occurs 200 times a day and you are very familiar with the program, it will become very noticeable. The speed of your network, not MediFile, is the problem.

With a wireless network, understand that it is a shared resource. If you have 10 computers working on a wireless network and that wireless network shares a 1 Megabit bandwidth, it is going to be substantially slower than the same computer wired to a 100 Base-T Network. In fact, it is going to be slower than the same computer wired to a 10 Base-T Network.

Today, 11 megabit wireless networks are readily available. This is a 10 fold improvement over the older 1 megabit bandwidth. Be aware, though, when you share it, that the speed is still much slower.

If you are using MediFile's Image Butler module and you are storing many images and bringing them up on the screen, you will aggravate an already slow network. By their very nature, images are much larger than the data streaming in MediFile between the client and the server.

Proper network design and planning is even more critical when using a wireless network.

Network Interface Card (NIC): The NIC is the hardware that connects the computer to the network. If this is bad, the computer will have problems on the network. Often the manufacturer will have software that tests the operation of the NIC internally. This will find some problems with the NIC, but not all of them. Since we have seen this problem with computers, MediFile as a good tool to test an individual workstation for this type of problem. We will discuss this later.

Software

For everything in a computer, there is software. This includes network operations. There are various levels of network software that can effect the network operation of MediFile. We will discuss this in relation to a windows computer.

Windows: The operating system itself needs to have software installed that will instruct the operating system how to interact with the NIC and the network as a whole. This software is configured by clicking on the properties of the Network neighborhood. We have seen where this has been corrupted (though it is configured correctly). To solve this issue, uninstall the network components and NIC software. Reinstall this and reconfigure. Before uninstalling this, write the configuration down so that it can be configured again.

4th Dimension: 4th Dimension server and client both have a file that is stored on the computer that tells 4th Dimension how to communicate with the operating systems network services. On Windows, this file is located at the following path:

Windows 95/98 --> Windows\Aci\Network\xxx
WindowsNT --> WinNT\ACI\Network\xxx

The component that we usually install is that which tells 4th Dimension how to communicate on a TCP/IP network. It will be called '4dnetcp.dll. As with all software, there are different versions of this network component. All computers running MediFile should have the same version of this software. If they don't, this can cause strange problems.

Look to the MediFile CD and ensure that all are the same version.

On windows there will also be a file that can be deleted in relation to the network. It contains configuration information for that computer in relation to the network component. With a TCP/IP network, this file is located at:

Windows 95/98 --> Windows\Aci\tcp.opt
WindowsNT --> WinNT\ACI\Network\tcp.opt

You can delete this file and it will automatically be created when you launch 4th Dimension on that computer. As with all files on a computer, this can become corrupted.

Troubleshooting Tips

There are several things that you can test and software you can purchase to determine network problems. Network problems are some of the hardest problems to resolve. The reason is that most people do not have the tools for the job, and they are often intermittent. There are also so many things that can contribute to the problem, because every device on your network can potentially cause the problem.

For example, you may have a perfectly functional network. Then a device totally unrelated to MediFile is installed on the network. This could be another computer, printer or instrument. If this device is configured incorrectly, it has corruption or hardware problems, or is not designed to work on the same network then it could interfere with the rest of the network. An example of this is the various forms of "attacks" that occur on the Internet. With attacks, someone has designed some software to interrupt the network services somewhere. There are many types of attacks. Essentially, though, a device (attacker's computer), is sending out signals that disrupt the network of the target network's computer.

For the reasons mentioned above, it is a very good idea to have a detailed and up-to-date record of your network and all the devices on the network. With this record should be kept all the dates of when something has been added or changed. This record of changes can assist in tracking down the problem if it started to occur after something was changed on the network. The changed item may not have anything directly related to the failing device(s), but it is interfering with it.

In trouble-shooting a network problem, there is software that can assist you. There is good software for this on both the MacOS, and Windows platforms. Be prepared though — this is expensive software. Also, it takes a technically knowledgeable person to understand how to set it up and interpret the results.

An example of software that we have used is EtherPeek from AG Group.

This type of software records all traffic on the network and keeps statistics on traffic loads etc. The software is installed on a computer on the network, configured and then left running for weeks to examine the network traffic.

Without the expensive software, there are things that you can do to test the network.

  1. Load Test in MediFile. As the administrator, you can go to the Admin corner special procedures. Run the load test procedure. This will create a lot of traffic from the computer you run it on to the server computer. This checks the workstation that you are running it on. If there are problems with the NIC, or the cable run from that computer this will usually show with this test. You will get a 1000x error if there are problems.
  2. Pinging: Built into Windows is a test you can use to test the network connection to another device at that moment. This test is "pinging" the other device. Drop down into DOS and, using the DOS command for pinging, ping the other device. This will return the time it took to get a response from the other device over the network. If some pings take a long time or fail, you know there is a problem with the network connection between the two devices. Of course there could be problems with the other device, or the computer you are on. For the MacOS there are several software solutions for this, one of the best being "ping." It does the same thing as the Windows DOS command, but has a nice graphical interface. This test is something for which it is good to keep a record of the times and problems between devices.
  3. File Copy: Another test of the network is copy a large file from one computer to another. A successful copy does not mean the network is fine. This is because built into the OS copying routines is error checking and auto request for a "re-send of data." You need to copy the file when the network is good. Record the time for the copy. You also need to do this at different times during the week/day to get a speed in different load conditions. Do this test with a 20 or meg file. This is a file large enough that a network problem is more likely to show up. The problem will show up in the file not copying or taking longer to copy. It is good to keep a record of the times and problems between devices with this test.
New Tools in MediFile

In MediFile version 3.x (likely not in the .0 release), Jonoke will be building in some more network testing tools. These will assist a system administrator in automatically tracking a history of the items mentioned in 2 & 3 above. For now you need to do this manually.

Jody Bevan
17 Feb 2000


Search jonoke.com:
Powered by FreeFindAbout this Search Feature

© 2003 Jonoke Software Development Inc.
info@jonoke.comsite mapprivacy policy