Ik heb er al 15 jaar niet meer van gehoord, maar ik kan intussen wel een oorzaak bedenken ...
Locktabel te klein.
Nou ja, zoiets en dan nog redelijk ver gezocht (ook al omdat dit volgens mij een Novell aangelegenheid was). Dus eerst moet iemand maar eens achterhalen of het fenomeen voor een Windows server nog bestaat.
Goed. Het valt op dat dit altijd bij precies dezelfde Boekingsregel in de Journalisering fout gaat. Dit is 100% zeker geen toeval. Ook valt het op dat het zo te zien nooit ergens anders dan bij Omvormen fout gaat (@Pascal ?). Verder is het klip en klaar dat als
anderen vrijgeven het Omvormen verder kan. Dit wijst wat mij betreft (best wel 100% zeker) op een algemene pool die vol is (vandaar het "Locktabel" idee).
Een ander datapoint is dat het onmogelijk is dat iets bij vdBosch "te groot" is in het algemeen en dan doelend op "zo veel gebruikers heeft vdBosch nou ook weer niet". Moraal hiervan : het moet iets zijn wat bij vdBosch anders is ingericht qua server, of eventueel qua installatie van VFP lokaal. Of zelfs dat VFP niet lokaal is geïnstalleerd terwijl dit wel moet. Of (bijna het meest voor de hand liggend) dat de caching op een andere manier werkt omdat er ergens aan "client" tussen zit die de boel vernaggelt. Ik denk aan de vroegere Novell client - iets wat het tegenwoordige Citrix ook zou kunnen (fout) doen. En let wel, het is feitelijk een netwerk probleem wat voor VFP alles met caching van doen heeft en wat met name lokaal (PC of WTS) gebeurt (veel minder aan de server zijde dus).
Buiten het Locktabel verhaal (wat, ik vrees, niet meer bestaat) kan je m.i. het beste flink achterover gaan zitten en
a. achterhalen sinds wanneer dit probleem bestaat;
b. kijken in alles log etc. wat er sindsdien is veranderd aan server en
iedere PC. N.b.: Ik denk niet dat je naar het netwerk zelf hoeft te kijken (dus ook geen switches en zo).
Ad b.
Als je nergens Windows 10 hebt, ben je van dat af als mogelijke oorzaak. Maar let op : waar ik normaliter gemakkelijk W10 van alles de schuld zou geven, denk ik dat dit in dit geval niet opgaat omdat er intussen te veel andere klanten en gebruikers aldaar met W10 werken (en ook met WS2016).
Wij zouden nog een log kunnen inbouwen van de uitgevoerde commands in deze Journalisering bij Omvormen (alleen daar dus) en als het euvel wederom optreedt kunnen wij
op dat moment kijken waar de boel stokt. Mochten wij daarvoor niet beschikbaar zijn op het betreffende moment, dan zullen we het achteraf ook wel kunnen vinden, als jullie aangeven wanneer (datum/tijd) het was en dan kijken wij wel naar de tijd die als het goed is ten tijde van het euvel "stil stond". Of dit ons echt helpt hangt een beetje af van de intelligentie van de log, waarbij ik alvast aangeef dat het NIET om Locken gaat, maar juist om zaken waar dit in de programmatuur niet gebeurt en VFP zelf iets doet (er zijn onvoldoende resources). Denk aan Append Blank. Wellicht is een log die ik bedoel niet eens goed mogelijk (tenzij we "Q" installeren maar dat vind ik wat ver gaan).
Overigens zou de aandacht nog kunnen gaan naar grootboekrekening 70000.0 of wat het ook is wat ik daar zie. En verder ... zie ik het goed ? wordt daar record 1 weergegeven ? Ik zou het toch denken ... En als dat zo is zijn we al 10x verder met
theoretisch zoeken. Of, met het inbouwen van log entries (immers, de manipulatie met record 1 bevindt zich in een beperkt aantal SY programma's).
Verder nog iets ?
