Johan, na wat onderzoek, komen wij met het volgende op de proppen. Althans, twee hoofdredenen. De eerste (engelse tekst hieronder) kan wat mij betreft op jullie van toepassing zijn, ook al vind ik het vergezocht. Echter, de reden waarom ik toch meen dat het kan, is omdat je ongeveer de enige bent die het heeft (volgens mij was er nog ergens iemand, maar die kan ik niet meer vinden).
Heb je inderdaad TTS aan staan, zet het dan eens uit; wij gebruiken dat niet.
Reden 1 :
SYMPTOMS
A FoxPro application running in a multiuser environment occasionally displays a message box containing this scrolling message:
Record not available ... Please Wait
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:
• Novell's Transaction Tracking Services (TTS) is active.
-or-
• There is a contention problem on the network server due to:
• Several users actively adding or updating records to a database where the CDX contains a large number of Tags or several very complex Tags.
-or-
• A large number of users are actively adding or updating records in a less than optimal network environment.
-or-
• Various combinations of the above.
The scrolling message results from FoxPro requesting a process from the network server and receiving a busy signal. This is not an error message, but rather an informational message from FoxPro. It is in essence saying "I have completed your transactions and handed off the update to the file server, but the file server is still working on completing some other updates to this file. Would you please wait?"
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.
If TTS is running, try turning it off. FoxPro does not provide direct support for Novell TTS. However, Novell provides a library (Nwtts.dll) that works with the FoxPro Library Construction Kit (LCK) to accomplish transactional processing.
Support for transactions has been implemented in Visual FoxPro. For more information, search for 'Transactions' in the Visual FoxPro Online Help. If TTS is not running, the problem is most likely a contention problem on the server. This means that the server is receiving more requests for processing transactions than it can deal with so they're backing up in the server's process queue. Eventually the server will catch up, the queue will be emptied out, and things will be back to normal.
Avoiding This Network Storm
It'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.
Merk nog op dat je met enige sjoege van de materie wel moet kunnen zien of de server het druk heeft op het betreffende moment.
Reden 2 :Deze is lastiger te herkennen, maar kan wat mij betreft heel goed aan de orde zijn. Hooguit geldt ook hier : waarom heeft niemand er last van en jullie wel;
N.b.: Waar bovenstaand engelse verhaal van Microsoft zelf is, (onder)kent MS kennelijk niet het navolgende.
Het blijkt -en wij hebben dat ook zojuist pas gevonden- dat er in Visual FoxPro een bug zit, dan wel dat er in het OS een bug zit (dit kan niet worden bepaald).
Kort door de bocht samengevat komt het erop neer dat waar je op de ene PC één record locked, je op de andere PC('s ?) meerdere gelockte records aantreft (dit is op zich de bug) en wat zich op die andere PC's uit middels de scrollende melding (normaal is de mededeling van het OS anders, en deze scrollende melding is het gevolg van niet afgevangen situaties (door het OS), op zich logisch waar de oorzaak een bug is (lees ook het engelse verhaal hierboven, want dan wordt dit wat duidelijker).
Overigens resulteert ook het draaien van een backup in de server (let op "in") in hetzelfde, wat dermate "hard" gebeurt dat van buitenaf gezien de server inderdaad "busy" is (zie weer engelse verhaal).
Gezien de aard van de bug (welke technische uitleg ik je verder zal besparen) mag worden verwacht dat dit bij grotere bestanden eerder optreedt. Laten we maar zeggen dat jullie Voorraadmutaties (LOVM) van 1,1GB "groter" is. Let wel, dit zegt niet alles, want anderen werken met bestanden tot aan de 2GB en hebben geen probleem.
Er zijn veel variaties die het probleem wat mij betreft beïnvloeden, zoals ook het netwerk OS. Dus het is maar vast gezegd : waar jullie Novell gebruiken (toch ?) hebben de meesten dat niet meer; op zich dus een reden om de bug niet tegen te komen.
Denkelijk nog belangrijker is de netwerk client, doch deze is veelal verbonden aan het netwerk OS. Dit hoeft op zich niet, want iedereen kan de MS client gebruiken, doch voor de hand ligt dit niet. Gebruiken jullie de Novell Client (waar op zich meerdere versies van bestaan) dan heb je dus weer een reden om de bug tegen te komen, waar anderen hem niet hebben.
Als de bug zich eenmaal gestand doet (en let wel, dat lijkt op zich standaard (
?)) dan hangt het vervolgens erg van de record lengte af. Zie het maar zo, dat als de recordlengte 100 is, er 1 record teveel wordt gelocked, is de lengte 101 worden er twee records teveel gelocked, bij 103 3 enzovoort, tot 200 dan is alles weer goed. Bij 201 weer 1 te veel enzovoort.
Gewoon een verzonnen verhaal, maar het principe dat de lengte er toe doet is wel van belang. Immers, die lengte verandert door de upgrades heen.
Johan, als je niet herkent dat het engelse verhaal aan de orde is, resteert het kleiner maken van LOVM als een poging om het op te lossen. Dit dus, gebaseerd op het (vermeende) gegeven dat de bestandsgrootte er toe doet (dit kan ik zelf niet bevestigen en de logika ontgaat mij ook). Helpt het dan helpt het, helpt het niet dan zitten we goed in de penarie, want ik zou niet weten wat er aan te doen.
Hooguit heb ik de hoop dat het onzin zou moeten zijn dat "we" die bug tegenkomen, want het zou voor het eerst in 20 jaar zijn. Maar goed, formeel bestaat ze ...
Houd voor jezelf, en het kleiner maken van LOVM in de gaten dat er ook nog iets is als een 1GB limiet waar de bug zich (in mijn theorie) manifesteert. Dus als je LOVM kleiner maakt, doe het dan zo dat je voorlopig de 1GB niet bereikt.
Als laatste de wellicht belangrijkste tip :
Ik heb redenen om aan te nemen dat het door elkaar gebruiken van VFP7 en VFP8 in deze uitmaakt. Verder durf ik er wel op te gokken dat jullie dat ook doen. Eigenlijk zou ik dan ook als eerste er voor zorgen dat alles onder VFP8 draait, gevolgd door het reorganiseren van alles (het laatste is zeer van belang).
Voor zover kritisch : houdt er rekening mee dat als je onder VFP8 reorganiseert, de indexen ongeveer twee keer zo groot worden ... opdat er niet ineens een disk ergens vol is.
Peter
