The information in this article applies to:
SYMPTOMSA FoxPro application running in a multiuser environment occasionally displays a message box containing this scrolling message: This message may scroll for a few minutes or for as long as an hour or more. CAUSE
FoxPro is receiving a busy signal when requesting a process from the
server. There are two possible causes for the busy signal:
RESOLUTION
A workstation that gets this message will eventually be able to complete
the pending process, although this could take a considerable amount of
time.
Avoiding This Network StormIt's important to note that because there is no error condition, there is no error to trap. Once this message appears, the network is already experiencing a network storm and the only resolution is to have all users stop what they're doing and wait for it to clear. The preferred approach is to take steps to avoid the storm in the first place.Two known approaches involve upgrading to a more powerful network or moderating the flow of process requests to the network server. While upgrading the network may be prohibitive, it is often relatively easy to moderate the flow of process requests to the server. Moderating the Flow of Process RequestsHere are two approaches you can use to moderate the flow of process requests to the network server:
Coding Techniques Effective in Dealing with This ProblemTwo coding techniques that have proven effective in dealing with this problem are: changing from record locking to file locking and introducing a wait state (delay) after adding to or changing any tables.Changing to file locking means that you use FLOCK() rather than RLOCK() when to add or change a record. It's important that you keep each lock only long enough to make the addition or change, and then release it. Although going to a file locking scheme may seem to be less efficient, it has the added benefit of spreading out process requests and leaves your program code in complete control. Because you are requesting a lock on the file before you process any records, you can provide more appropriate options when locks are unavailable due to heavy traffic. In effect, you are shifting processing control from the server to your program. You can add a delay by including a WAIT "" TIMEOUT n command immediately after releasing the file lock. To help spread out process requests to the server, you can vary the amount of time to wait (specified by n) depending on the time it takes to obtain the lock. One algorithm to accomplish this calls for requesting the lock within a loop and counting the iterations until the lock is obtained. Then use this count in a formula to arrive at a delay time. The longer it takes to obtain a lock, the longer the wait state. When you consider this taking place on several (or many) workstations, the net effect is to flatten out the flow of process requests to the server. This eliminates the peak conditions that result in the network storm. STATUSThis behavior is by design. Additional query words: novel
Keywords : kbnetwork kbVFp FoxWin FxnetworkOther |
Last Reviewed: October 19, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |