Heart-Profit ERP

We krijgen de laatste tijd regelmatig een vastloper wanneer we een artikel omvormen.

Menu 1-4-3-1 Raadplegen voorraaditems, F2 F omvormen (1e schermafdruk).
Je ziet dan de melding linksbovenin (2e schermadruk).
Rechtsbovenin het scherm staat 'Record not available' (zie 3e schermafdruk).

Soms gaat hij door wanneer iemand in het bedrijf Profit vrijgeeft.
Dat kan iemand van de administratie zijn, of bv iemand van de klantenservice.
De overlevering vertelt helaas niet in welke funktie ze op dat moment zaten.
Maar 'vroeger' hadden we dit probleem bij het omvormen nooit.

Hmm... ik kan nu even niet zoeken op het forum, maar, ik denk dat dit te maken had met het feit dat een bepaalde tabel (ADOB) te groot aan het worden is. De data die daarin zit wordt zo goed als niet gebruikt, dus, ik ben die even wat aan het opschonen. Als dat klaar is, zul je vanavond even tabel ADOB moeten reorganiseren (als iedereen die tabel heeft vrijgegeven), dan vermoed ik dat het probleem is opgelost.

Nb: Merk op dat ADBO ook de 2 GB grens aan het benaderen is.

Ok dank alvast. ADBO zit al op 1,88Gb > ik check de verkenner en zie dat dit alweer 1.971.400 kB is.
Mocht de ADBO nu 1,99Gb zijn, of maar 1.999.999 kB? Want dat 2e komt al heel snel dichtbij.

1,99 GB.

ADOB heb ik opgeschoond, en is gereorganiseerd. Ik vermoed dat je 'record is not available' nu verdwenen is.

Dank je - wanneer het nog eens voorkomt meld ik me.

Ok.

Weet overigens dat we voor andere grote tabellen, zoals jouw ADBO, ook gewoon 'opschoonfunkties' hebben. Zo zouden we met een runnetje ervoor kunnen zorgen dat we alle boekingen van bijvoorbeeld 1999 t/m 2009 historisch maken, hetgeen vast wel aardig wat ruimte vrijmaakt in ADBO om er weer jaren tegenaan te kunnen. Het runnetje wat ik dan in gedachte heb, verwijdert hooguit de mutaties, maar verandert niets aan je periode totalen. Je kunt dan dus nog gewoon balansen blijven printen, maar, alleen op periode grenzen (dus heel januari 1999, maar niet van 3 januari 1999 14:00 t/m 16 januari 1999 20:00). Vanzelfsprekend kun je ook geen boekingsmutaties meer opvragen over de perioden waarin je e.e.a. verwijderd hebt, maar... of je nog zoveel doet met 1999 t/m 2009?

Merk daarbij ook op dat we je data niet echt 'weggooien'; ze wordt formeel 'historisch' gemaakt. Mocht je ooit besluiten over te stappen op een onderliggende database die in staat is om met veel meer data overweg te kunnen (Advantage Database Server) dan wordt die data bij de migratie naar ADS gewoon weer toegevoegd.

Helaas gaat het nog steeds fout bij het omvormen.
Hij liep wel door toen collega die in statistieken zat (menu 8-...) Profit vrijgaf.

Bedankt trouwens voor de suggestie mbt ADBO - ga het overleggen.

Pascal, de situatie waar Wouter het over heeft van "te groot worden" in deze, betreft niet 2GB maar rond de 1GB (2GB is domweg een harde limiet en als je die overschrijdt gaat het echt fout). Dus sorteer eens op grootte in ieder van de directories (LOPF en ADPF zal wel voldoende zijn) en kijk eens of tabellen rond de 1GB zijn (zeg even van 950MB tot 1.1GB en daarboven is niet erg meer - tot 2GB natuurlijk).

Voor zover van belang, vergeet niet dat 1GB niet 1.000.000 enz. is, maar 1.024xxx.

Ok - ik heb even gekeken. De grootste bestanden op G:\FOX\LO\LOPF en G:\FOX\AD\ADPF staan hieronder.
Naast ADBO.DBF komt alleen LOOA.DBF in de buurt van de 1Gb.

Misschien heeft iemand die bestanden wel open in Excel :wink: ...

Merk op dat het 1 GB probleem leidt tot een 'record is not available' en die melding in de recentelijk geplaatste schermprint er niet meer staat.
Er staat nu hooguit 'reageert niet' wat gewoon echt even zo kan zijn omdat er iets anders druk is.

Over die 'reageert niet'... ik ben niet 100% zeker of deze wel of niet in het scherm stond. Op m'n foto van mobiel valt meest rechtse deel v/h scherm weg.

Ik weet wel dat in dit geval een administratie-medewerker in statistieken zat (menu 8-...).
Dus heel goed mogelijk dat hij iets met Grootboek 70000.0 deed / bezet hield. Temeer omdat het probleem was opgelost op het moment dat de administratie-medewerker F10, F7 deed in Profit.

Ik hou het vooralsnog in de gaten - wanneer het scherm weer verschijnt check ik de oorzaak. Dus of het opnieuw komt doordat iemand in de Statistieken zit en/of het opgelost is wanneer deze Profit vrijgeeft.

Het probleem blijft zich voordoen, bij deze de schermafdrukken.
Misschien dat jullie met deze info iets kunnen?

Administratie en mensen van Klantenservice laten vrijgeven, maar dit loste het probleem niet op (er stonden nog wat sessies open van mensen die van de plek waren die we niet snel konden bereiken, dus niet bij iedereen is Profit vrijgegeven).
Vervolgens Profit afgebroken en Profit opnieuw gestart en gereorganiseerd. Het omvormen is wel goed gegaan zover we konden zien.

Uit je laatste schermprint blijkt dat je nog steeds 'Record is not available' krijgt. Tsja... de enige tabel die hier gebruikt wordt (in AD) en die boven de 1 GB zit, is ADBO zelf met 1,86 GB. Ondanks dat hier net zo goed 'Record is not available' op zou moeten kunnen voorkomen, zijn we dit in praktijk nog niet tegengekomen, behalve nu bij jullie, waarbij ik er vanuit ga dat het ADBO moet zijn bij de gratie dat dit de enige tabel in AD is die nu nog boven 1 GB zit.

Een oplossing, behoudens de ADS versie van Profit, zou hem zitten in het opschonen van de tabel ADBO.

Ik heb die tabel zojuist even wat voor je geanalyseerd:

De tabel is nu 1,86 GB groot.
Ondanks dat je er ook andere administraties in voert, komt zo'n 99% van je boekingen uit BBB-BETON.

Stel dat we alleen voor bedrijf BBB-BETON de ADBO mutaties opschonen van 1999 t/m 2011 dan zou dit je ADBO bestand met zo'n 1,12 GB doen verminderen. Over die periode kun je dan gewoon nog steeds rapporteren, mits op periode grenzen (je periode totalen blijven immers bestaan); mutaties kun je niet meer opvragen, maar ja, doe je dat nog over 2011 of daar voor?

Je ADBO zou dan van 1,86 GB naar 0,74 GB gaan waarmee ze ver genoeg onder de 1 GB komt om dit probleem niet meer te laten optreden.

Heb het even besproken - hoe klein wordt ADBO wanneer je t/m 2007 of 2008 verdicht - is dit ook voldoende?
En als ik het goed begrijp kun je alle data weer importeren wanneer je overgaat op ADS?

Toevallig had ik vanmorgen ook t/m 2009 onderzocht, en dat zou uitkomen op ongeveer 0,87 GB.
Daarmee zou je uitkomen op 1,86 - 0,87 = 0,99 GB en zit je morgen alsnog weer met hetzelfde probleem.
T/m 2010 eruit zou op 1,86 - 0,99 = 0,87 GB uitkomen wat in theorie ook nog net zou kunnen.
Minder dan t/m 2010 zal dit probleem niet oplossen.

Mm.. Financiele afdeling is niet zo happig op het verdichten.. vooral niet zoveel jaren - hij wil graag weten waarom het nu optreedt en niet al eerder, omdat het bestand al jaren groter dan 1Gb is.
Ik kan hem die verklaring helaas niet geven..

Ik ook niet.  :(

Zoals ik al zei, op ADBO hebben we hier nooit last van gehad.

Technisch gezien treed het probleem op omdat als de tabel groter is dan 1 GB, de recordslocks in die tabel op dezelfde plek worden 'geregistreerd' en je niet meerdere recordslocks aan kunt (zoiets). Het resulteert in 'Record is not available'. De theorie kan dus zijn dat dit bij ADBO nooit optreedt, omdat een record gemaakt wordt, beschreven wordt, weer wordt vrijgegeven, en daarna enkel nog maar gelezen wordt, maar nooit gelockt.

Wat mij betreft heb je te weinig boekingen om dit 'grote boekingsruns' te kunnen laten liggen die tegelijk worden uitgevoerd. Vandaar ook de opmerking, kan de lock niet door wat anders worden veroorzaakt, bijvoorbeeld Excel (of in theorie zelfs een backup).

Als je hier echt nooit eerder last van hebt gehad, misschien is er op de server iets in de war en helpt het rebooten van de Server.
Of misschien herken je wel dat je recentelijk andere dingen met boekingen bent gaan doen en dat daar iets in zit wat (onnodig) boekingen lockt?

Voor de broodnodige verwarring (en in tegenstelling tot wat Wouter lijkt te suggereren) :
Wij kennen geen situatie dat er boven de 1GB (en onder de 2GB) een dergelijk probleem optreedt. De "record not available" treedt maar in 1 situatie op : als het bestand tegen de 1GB is. En dat dan ook nog met een geringe kans.

Het moet hier dus iets anders betreffen.

Ik ken verder nog twee omstandigheden waarbij dit ellendige ding optreedt :
- Server in de war (o.i.d. maar reboot helpt);
- Backup of dat soort geheimzinnige software heeft het bestand gelocked (lees : op eigenlijk oneigenlijke wijze).

Als iemand meer weet dan hoor ik het wel, maar dan wel met bewijs en naam+toenaam graag.

Ok, dank voor de toelichting en suggesties.
Wat ik sowieso ga doen is komend weekend de Profit-server herstarten.

Zal dan gelijk kijken of er ergens Excel-bestanden open staan, of gebruikers die sessies al dagenlang hebben openstaan (het probleem doet zich nl pas sinds 1,5 week voor). Deze sluit ik dan ook af.

Van onze backups krijg ik dagelijks de log-files op de mail, deze controleer ik ook dagelijks. Nooit errors mbt Profit-databases. De backup-jobs worden altijd netjes 's nachts op tijd afgerond. Maar ga toch even kijken of ik daar iets geks kan vinden.

Ik laat uiteraard weten of het iets oplevert en zoniet, of de herstart het probleem heeft opgelost.

Ja, je hebt helemaal door waar je naar moet kijken.
Houd wel in de gaten dat als je begint met rebooten en het helpt, je daarna ook niet weet waaraan het lag. Maar dat gebeurt echt wel vaker, dus ga gerust je gang. :smile:

Mooi, dank je.
Ik zie dat de Profit-server inmiddels een uptime heeft van 178 dagen, dus onstabiel is het in elk geval niet :wink:

Mijn PC kan er ook wat van. En die 105 dagen is dan nog omdat ik een keer DACHT dat 'ie het niet deed. Maar ja, als schoonmaaksters voorbij komen blijven ze wel eens aan de monitor kabel hangen (die ik nooit vast schroef). Anders was deze wel over het jaar geweest.
Alleen stroomstoringen gooien wel eens roet in het eten. :bored:

Haha, netjes hoor.
Grappig, dat doe ik ook niet. Na verloop van tijd krijg je die *(#@ schroeven ook niet meer los, of komt het moertje waar t inzit mee...  :(

Ik zou nog laten weten of onderstaande acties hebben geholpen (niet afgelopen weekend maar het weekend daarvoor uitgevoerd):


Ik heb evt openstaande sessies afgesloten (Profit of 1 van de databases stond op dat moment niet open), backups gecontroleerd (ook in orde, allemaal keurig voltooid en afgesloten), vervolgens de Profit-server herstart.

We zijn een week verder, maar ik heb nog geen meldingen/vastlopers meer gekregen mbt het omvormen - al is het wel zo dat het (ivm vorst) rustig is, dus ik hou nog een slag om de arm.

Komt het probleem toch nog terug dan meld ik me.

Hebben jullie de normen qua "vorst" aangepast of zo ?
Vorst is bij mij -5 en kouder. Liefst -20.
Maar dat gebeurt niet meer ...

De dreiging van vorst zorgt er al voor dat bestellingen opgeschort worden  :wink:

Maar ik krijg net de melding dat het omvormen weer blijft hangen (MH), zie 1e afbeelding.
Vervolgens Dinand (DdL) gebeld - hij zat in Raadplegen Saldo op een tijdstip. Gevraagd F10, F7 vrijgeven te doen (2e afbeelding).
Op het moment dat hij dit doet wordt de omvorm-opdracht afgerond. Geen verdere foutmeldingen.

Hopelijk kunnen jullie hier iets mee?

Blijft allemaal een raar verhaal  :(

Raadplegen saldo van een Grootboekrekening zou als het goed is niets moeten locken, en zou daarmee een PC die boekingen staat te genereren niet moeten kunnen tegenhouden. Kortom, heb je dit echt goed gekonstateerd, of kan het op toeval berusten?

Nog even wat verder kijkend naar dat Omvormen, dan zie ik daar op zich wel wat mogelijkheden die roet in het eten kunnen gooien.

Als eerste haal ik uit je schermprint dat je LOVIRA met een Userbutton aanroept (dat kan op zich al voor ellende zorgen).
Dan kom je in LOVIRA, selekteer je een Voorraaditem, en ga je naar het V-item menu, alwaar je optie F- Omvormen gebruikt.

Optie "F" Omvormen roept LOVIOT aan, alwaar je je Voorraaditem omvormt. LOVIOT maakt Batchboekingen aan, maar, let op.. boekt deze pas door als je op Escape drukt om terug te keren van LOVIOT naar LOVIMN. Ook dat kan voor ellende zorgen.

Als klap op de vuurpijl kom je daarna terug in LOVIMN (zie jouw schermprint), alwaar een Voorraaditem wordt geacht geselekteerd te zijn die er inmiddels niet meer is omdat je die hebt omgevormd.

Niet geheel toevallig vorm ik zojuist bij mij iets om, en staat dit (de 1e keer) ook even lang te wachten. En zoiets herken ik dus wel als 'reageert niet' bijv. omdat het systeem intern op een plek is uitgekomen met bijv. een hele boel verwijderde records die hij nu intern staat te skippen (wat dan weer heel toevallig overeen kan komen met de tijd die je nodig had om DDL vrij te laten geven).

Het eerste wat mij niet aan staat in deze werkwijze (ooit vast en zeker zelf bedacht) is dat er op de terugweg wordt gejournaliseerd. Dat zal uit het DOS tijdperk komen, en i.g.v. Windows gebeurt er gewoonweg teveel om dat op deze manier te mogen laten verlopen. Zojuist een aanpassing op jullie systeem geplaatst die direkt journaliseert nadat er is omgevormd. Ben benieuwd of dat helpt.

In ieder geval moet die aanpassing ook opleveren dat als de handel straks nog een keer hangt, de informatie m.b.t. doorboeken nog op het scherm staat (en het probleem dus 'Doorboeken Batchboekingen' georienteerd is) of dat die teksten al van het scherm verdwenen zijn, en het probleem te maken heeft met de terugkeer naar een Voorraaditemmenu van een Voorraaditem welke inmiddels niet meer bestaat (omdat ze is omgevormd).

Tsja... en dan kan de plank dus alsnog helemaal misgeslagen worden als het inderdaad zo is dat het vrijgeven van DDL jouw probleem oplost. :wink:

Nb: Overigens zojuist een 1020GRIJK op voorraad gelegd, omgevormd naar 1020GRIJM en weer terug, en dat lijkt allemaal te werken.

Wouter, dank voor het uitzoek-werk.
Hopen dat dit het probleem wat duidelijker maakt (of wellicht opgelost heeft, wie weet).


Wanneer we tijdens het omvormen weer 'vastlopen' (tussen haakjes uiteraard), dan zal ik kijken en terugkoppelen wat ik op het scherm zie.
Dinand dus ff polsen of hij weer in ADST of soortgelijk menu zit, maar zal hem niet meteen vragen vrij te geven.

Ik hou je op de hoogte!

:swoon:

:yes: ...eerst kijken wat er op 't scherm staat en of hij toch niet alsnog het omvormen afrondt binnen een aantal minuten, zie opmerking Wouter:


Zoniet, mag hij vrijgeven en kijken we of daarmee het omvormen meteen afgerond wordt.

Het hangen van het systeem bij het omvormen komt momenteel vrijwel dagelijks voor.
Ik heb het volgende geregistreerd:

Gebruiker MH gaat omvormen en scherm blijft hangen. 10 minuten afgewacht, scherm blijft zoals hij is (zie schermafdruk 1 - scroll je naar rechts dan zie je ook blokje 'Record not available').
Gebruiker LV heeft funktie LOILRCRA Raadplegen Ontvangsten op Leverancier openstaan (schermafdruk 2).
Profit staat gewoon open maar ze is in Word aan het werk.
Programma HeartProfit weer aangeklikt, naar hoofdmenu gegaan en Vrijgeven Gegevens aangeklikt (knop met groene mapje).
Vervolgens gekeken wat er op scherm MH gebeurt > zie schermafdruk 3. Hij kan nu verder.

Hopelijk helpt dit bij het vinden van een oorzaak.
:17c:

Top. Lijkt me in ieder geval een aanwijzing waar we mee verder kunnen. Gaan we mee aan de slag!

Je vorige topic leek te impliceren dat het LOILRCRA scherm "iets" gelockt houdt, en dat de ellende veroorzaakt. "Na Vrijgeven" kon je op de andere PC weer verder.
Dit onderzocht, maar, niets kunnen vinden.  :(

Nu is LOILRCRA ook maar een 'gewone Raadpleegfunktie', en die lockt op zich niets. Het gaat erom wat de gebruiker daarvóór gedaan heeft...  "Ontvangsten Korrigeren" bijvoorbeeld, maar, die heb ik ook al getest, en houdt ook geen recordlocks open staan...

Andere invalshoek: direkt ná het doorboeken aktiveert Profit een VTV Berekening o.b.v. een ingestelde bedrijfsparameter.
Dat betreft op zich ook een zeer heavy use funktionaliteit, welke niet voor jullie ontwikkeld is, en waarbij ik me kan afvragen of jullie hier bewust mee werken. Ik vermoed van niet!

Binnen dat ontwerp wordt bij alles wat je doet wat ook maar enigzins van invloed kan zijn op de VTV van een Artikel, een 'VTV Herbereken-vlag' aangezet. Op de achtergrond word je geacht een Batchprocessor te hebben draaien die 100% van zijn tijd alleen maar VTV berekeningen staat uit te voeren, en diens resultaten opslaat in een tabel op het netwerk. Alle andere werkstations kunnen dan (zonder de data opnieuw te berekenen) hun data halen uit de op het netwerk opgeslagen VTV resultaten. Dit soort resultaten worden meestal voor de eerst komende 7 dagen vooruit berekend, en voor iedere dag opgeslagen.

Bij jullie is e.e.a. wel geaktiveerd (Tabblad #5 van Artikel parameters), maar het aantal dagen vooruit berekenen heb je op 0 dagen staan. Die kombinatie is dus al raar, en lijkt te impliceren dat iemand er gewoon een vinkje heeft geplaatst, terwijl je niet de bedoeling hebt dit als zodanig te gebruiken. Als ik daar gelijk in heb, zou het advies zijn om dat vinkje bij "Resultaten VTV berekening op netwerk opslaan J/N" weg te halen. Geen idee of het helpt, maar, 't zou kunnen, immers, als dit aan staat, kunnen geen twee gebruikers tegelijk met dezelfde Artikel-/Verschijning bezig zijn.

Als ik wat achter de schermen in je Batchboekingen tabel wil harken, dan gaat dat ook langzamer dan verwacht. Sluit dus ook niet uit dat het daar met een index te maken heeft.  ADBB zojuist even wat opgeschoond en opnieuw gereorganiseerd.  Hoop dat je morgen al verbetering kunt merken. Zet die parameter uit het vorige punt nog even uit (als je dat niet gebruikt).

Dank je Wouter, we gaan kijken hoe het nu gaat.
Ik heb vinkje 'Resultaten VTV Berekeningen op netwerk opslaan' gistermiddag uitgezet, maar dit leverde problemen op (er liepen 2 mensen vast die grondstoffen aan het opboeken waren). Was eind v/d dag dus heb het vinkje snel even weer aangezet en na herstarten van Profit bij die 2 ging het weer goed.

Blijkbaar heeft het toch invloed op de werking van ons systeem, ik wil het nog wel eens testen maar dan doe ik dit gecontroleerder en ga ik eerst eea testen.

Ik houd je op de hoogte!

Welke problemen leverde dit op? Waar liepen die 2 mensen op vast? Misschien handig om te noteren, dan kan ik er iets mee.

En, bij het vinkje aanzetten beschrijf je dat ze Profit herstart hebben, maar bij het uitzetten niet. Kan er in theorie ook mee te maken hebben (maar zie vorige punt).

En? Al verbetering? Of doet het probleem zich nog steeds voor?

Ik moet bekennen dat ik nog moet testen of het vinkje 'Resultaten VTV Berekeningen op netwerk opslaan' uitzetten helpt. Paar andere belangrijke zaken prioriteit moeten geven.
Maar dag dat ik vinkje uitgezet heb werden er problemen geconstateerd bij het opboeken van grondstoffen (2 collega's), dus even rustig testen is wel belangrijk denk ik voordat ik m zomaar weer uitzet.

Wel is het zo dat het uiteindelijk altijd opgelost wordt wanneer de juiste collega in Profit naar het hoofdmenu gaat.

Ik heb ook gezien dat Profit weleens open staat ergens terwijl collega naar huis is.. Heb nu net rondgemaild dat je Profit af moet sluiten wanneer je vertrekt en naar hoofdmenu moet gaan wanneer je langere tijd van je plek af gaat. We zijn benieuwd hoeveel effect dit gaat hebben.

Dat is wel zo en dat is wel goed, maar nooit behoort dit de "Record not available" te impliceren. OK, kan denkelijk ergens wel gebeuren in een voor ons onverwachte situatie (die we niet eens kennen) maar het uitvaardigen van "iedereen snel terug naar het hoofdmenu !" is overdreven.
Eeuwig in wijzigen Produktieorder (of 1000 anderen) blijven zitten moet je niet doen want dan krijg de rest "De gegevens zijn geallokeerd door een andere gebruiker". Maar naar die situatie zijn we helemaal niet op zoek ...

Het probleem blijft zich voordoen (dagelijks), mensen van administratie en klantenservice naar hoofdmenu laten gaan en laten vrijgeven lost het probleem op.
Mogelijke oorzaak is dus de ADBO.DBF die tegen de 2Gb groot aan het worden is.
Hier moet toch een keer iets mee gebeuren, dus na overleg met Dinand besloten dat 1999 t/m 2010 gecomprimeerd mogen worden voor ADBO bedrijf BBB-BETON.
En dan wel zodanig dat je per jaar kunt blijven rapporteren uit deze periodes.

Ik geloof er niets van. Maar we gaan het binnenkort zien. :smile:

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 ? :smile:

Dit klopt. Het gebeurt enkel en alleen bij het Omvormen.

Volgens mij staat er idd altijd hetzelfde record en dezelfde grootboekrekening weergegeven (alle 3 gevallen hierboven).
Van mij mag je eea gaan loggen en kan ik bellen wanneer het weer fout gaat bij het omvormen.
Hopelijk kan daarmee een oorzaak gevonden worden.

Zijn jullie al aan het loggen?
Dan bel ik wanneer iemand vastzit tijdens het omvormen.
(Vanmorgen is het weer een keer voorgekomen bij gebruiker MH, maar voor het melden hiervan ben ik nu uiteraard rijkelijk/te laat.)

Neu, dat loggen hadden we nog niet aktief (/ gemaakt). Gaan we nu maar eens doen ...
:17c:

Top, wanneer dit draait ga ik bellen igv een nieuwe vastloper.

Zodra e.e.a. aktief is zullen we het hier melden.

Logging is vanaf heden aktief. Op een aantal strategische plekken wordt geregistreerd dat dat punt bereikt is, c.q. wat specifieke 'waarden' op dat moment zijn. Ik hoop dat we daarmee wat verder komen. Zodra een werkplek hangt, neem dan meteen even contact op.

Ga ik doen - ik bel wanneer we vastlopen. Dank!

Wouter, is de logging nog steeds aktief?
En kan ik je bellen wanneer ik de vastloper tijdens omvormen op m'n scherm heb staan?

Ja die logging is nog steeds aktief.
"Kan ik je bellen"?
Ja, tuurlijk, maar, dat zou je sowieso al doen!
Met als uitgangspunt dat je al een half jaar niet meer gebeld hebt, ga ik er vanuit dat het probleem nooit meer is opgetreden.  Of toch wel soms?

Dat wel, maar hij werd niet altijd lang genoeg geblokkeerd of men 'wilde door' en liet iedereen vrijgeven maar dan kunnen jullie niet meekijken.
Nu kan ik echter zelf af en toe deze fout op mn scherm toveren dus kunnen jullie rustig onderzoek plegen en evt met Teamviewer het scherm overnemen mocht dat nuttig zijn.
Vanmorgen dus even zelf kunnen laten blokkeren op mn scherm, maar die kwam 'helaas' uit zichzelf weer vrij.

Als ik 'm nu voor langere tijd kan laten vastlopen meld ik me  :smile:

Toch is dat niet handig  :( want een half jaar geleden wisten we wat we aan het testen waren, en nu zullen we dat weer opnieuw moeten uitzoeken, teruglezen, bla bla bla. Smeedt het ijzer als het heet is, en laat het niet een half jaar afkoelen.

Klopt helemaal, oorzaak dat het is blijven liggen is dat het is lastig na te spelen (heb me gisteren suf omgeboekt terwijl er fakturen geboekt werden en de bank gedaan werd, toch geen 1x geblokkeerd). Het gebeurt heel willekeurig lijkt het maar komt altijd erg ongelegen en dan is de oplossing mensen vrij laten geven en weer door.

Het gebeurt altijd bij een gebruiker (MH) waar je het scherm niet van over kan nemen. Is dit nodig, of hoeven jullie alleen maar onder eigen account in het systeem te kunnen om de oorzaak op te sporen?

Dat zei ik, geen idee, moet nu eerst weer uit zoeken wat we allemaal loggen. Na een half jaar heb ik echt wel 1000 andere dingen tussendoor gedaan, en zit ik hier niet meer in. :( We zoeken het wel uit tegen de tijd dat je het weer eens aan de orde hebt; nu heb je het ook een half jaar laten liggen.


Het betreft dus altijd maar 1 gebruiker? Wisten we dat al?
Kan het niet gewoon door aan zijn PC liggen?  :smile:

Zojuist even uitgezocht, en maar meteen hier gedocumenteerd, opdat we een volgende keer niet weer het wiel hoeven uit te zoeken.

Uitgangspunt is dat dit fout gaat vanuit Omvormen Voorraaditem.

In die funktie is een logfile ingebouwd, die per Omvorming een logfile aanmaakt (G:\FOX\SY\ER\LOVIOT_<userid>.RNA).

In die logfile worden 'het bereiken van diverse stappen gelogd' vanaf het moment van op F1 drukken, tot de terugkeer in het scherm.

Als voorbeeld (misschien meer voor ons dan voor jullie):

---

23-11-2018/11:25:27.89 Bedrijf = BBB-BETON; User = MH ; Artikel BKK8GRIJM; VrsVorm ST; Charge 100485; Aantal x Inhoud : 50000 x 1.000
23-11-2018/11:25:28.02 LOVIOTF1 : Doorboeken Batchboekingen
23-11-2018/11:25:28.04 ADBOTVW1 : Begin
23-11-2018/11:25:28.05 ADBOTVW1 : Journaalpost-id = LOVIOT       
23-11-2018/11:25:28.05 ADBOTVW1 : MULTILOCKS ON
23-11-2018/11:25:28.06 ADBOTVW1 : Voor aanroep ADBOTVW2
23-11-2018/11:25:28.06 ADBOTVW2 : Begin ADBOTVW2
23-11-2018/11:25:28.06 ADBOTVW2 : SYS
23-11-2018/11:25:28.06 ADBOTVW2 : Regel=1; JP Status = GOED; LOOPIND_W = D
23-11-2018/11:25:28.07 ADBOTVW2 : Batchboeking Vnr=0; Regel=1     ;Rekening=70000.0; User=MH ; Oms=OV/OG van BKK8GRIJM/ST/ATE12 (50000x1,00
23-11-2018/11:25:28.07 ADBOTVW2 : ADBOBO naar Hulpbestand
23-11-2018/11:25:28.08 ADBOTVW2 : Regel=2; JP Status = GOED; LOOPIND_W = D
23-11-2018/11:25:28.09 ADBOTVW2 : Batchboeking Vnr=0; Regel=2     ;Rekening=70000.0; User=MH ; Oms=OV/OG naar BKK8GRIJK/ST/ATE12 (50000x1,0
23-11-2018/11:25:28.09 ADBOTVW2 : ADBOBO naar Hulpbestand
23-11-2018/11:25:28.10 ADBOTVW2 : Regel=3; JP Status = GOED; LOOPIND_W = D
23-11-2018/11:25:28.10 ADBOTVW2 : Regel=3; JP Status = GOED; LOOPIND_W = D
23-11-2018/11:25:28.10 ADBOTVW2 : Einde ADBOTVW2
23-11-2018/11:25:28.11 ADBOTVW1 : Terug na aanroep ADBOTVW2
23-11-2018/11:25:28.11 ADBOTVW1 : ADBOBO Hulpbestand doorboeken
23-11-2018/11:25:28.11 ADBOBO   : Doorboeken - tijd = 212409775528
23-11-2018/11:25:28.12 ADBOBO   : Doorboeken -    1|Grtbk|70000.0       |~             |OV/OG van BKK8GRIJM/ST/AT
23-11-2018/11:25:28.13 ADBOBO   : Doorboeken -    2|Grtbk|~             |70000.0       |OV/OG naar BKK8GRIJK/ST/A
23-11-2018/11:25:28.14 ADBOBO   : Bijwerken saldo rekening 70000.0       
23-11-2018/11:25:28.15 ADBOBO   : Bijwerken saldo rekening 70000.0       
23-11-2018/11:25:28.16 ADBOTVW1 : Na doorboeken ADBOBO
23-11-2018/11:25:28.16 ADBOTVW1 : Historisch maken Batchboeking Rgl 1
23-11-2018/11:25:28.17 ADBOTVW1 : Historisch maken Batchboeking Rgl 2
23-11-2018/11:25:28.17 ADBOTVW1 : MULTILOCKS OFF
23-11-2018/11:25:28.17 ADBOTVW1 : Verwijderen Batchboeking Rgl 1
23-11-2018/11:25:28.18 ADBOTVW1 : Verwijderen Batchboeking Rgl 2
23-11-2018/11:25:28.19 ADBOTVW1 : MULTILOCKS OFF
23-11-2018/11:25:28.19 ADBOTVW1 : ZAP ADBH
23-11-2018/11:25:28.20 ADBOTVW1 : Einde ADBOTVW1
23-11-2018/11:25:28.20 LOVIOTF1 : Einde Doorboeken Batchboekingen
23-11-2018/11:25:28.21 Na aanroep LOVIOTF1, terug in LOVIOT

---

Deze logfile wordt uniek gemaakt per gebruiker, dus, als het fout gaat, en jullie de naam van de gebruiker weten op te hoesten (MH) weten wij welke logfile we moeten bekijken. De logfile wordt overschreven bij iedere volgende omvorming, om te voorkomen dat er een logfile van hier tot Tokyo wordt opgebouwd.

Resumer:
Zodra een gebruiker de 'Record is not available' melding krijgt, moeten jullie opbellen! dat je een PC vast staat met die melding. Op dat moment dus vooral nog even niet naar iedereen rondschreeuwen dat ze vrij moeten geven, want dan gaat e.e.a. mogelijk weer verder. Toch, mocht dat toevallig gebeuren, dan kunnen we dit aan de gelogde tijd wel weer herkennen (als er maar even wat herkenbare tijd tussen zit). Wel is het van wezenlijk belang dat die gebruiker niet nog een keer gaat omvormen (ook niet op een ander werkstation) tot wij de logfile hebben veiliggesteld.

Nee, we hoeven NIET op de PC van die gebruiker in te loggen om de logfile te kunnen bekijken; dat kunnen we ook vanaf de inbel pc doen.

Doel van de logfile is dat we kunnen achterhalen of, en waar het in de journaliseringsmodule fout loopt. Daarmee hebben we vast en zeker nog niet meteen de oorzaak gevonden, maar, als we een stukje verder komen in de richting, kunnen we de logfile daar weer op laten focussen.

Super, duidelijk!
Ik ga bellen wanneer een gebruiker de melding op het scherm krijgt bij het omvormen.

Ik zou het toch iets slimmer vinden als de log file wel van hier tot Tokyo wordt. Dan mag het wel "tijdelijk" optreden en als er dan maar wordt gebeld wanneer (datum/tijd) het is gebeurd, kunnen we wat mij betreft hetzelfde zien als dat je meteen belt, plus dat het een keer handig kan zijn dat we meerdere situaties qua overeenkomst met elkaar kunnen vergelijken.

Overigens is een log file van pas hier tot Tokyo als 'ie een 20MB groot is. Is nog niet erg, maar dan begint inlezen in Notepad wat lastiger te worden. Verder zal je die 20MB een keer kunnen bereiken als je deze hebt omgevormd :
:17c:

M.i.v. heden aktief.

Super, ik bel wanneer het weer voorkomt.

Haha... 1 van de logfiles staat in 3 dagen tijd op 2 Mb, dus dit kan sneller gaan dan verwacht...

Maar... op zich werpt het al wel vruchten af, in zoverre dat we nu kunnen zien of, en wie, er nog meer aan het journaliseren was toen de melding optrad.

Bij het journaliseren zijn er meerdere plekken waar boekingsrecords worden aangemaakt; we weten nu bij welke het fout gaat. De logging is daar nu verder op aangepast, zodat we wat en volgende keer beter inzicht hebben op het specifieke commando waarop het foutloopt.

Gebruiker MH kreeg "Record is not available" om 09:23 en kon om 09:34 weer verder. Er zijn naast MH nog 3 andere gebruikers die gejournaliseerd hebben vandaag: JAS, LV en DDL.

DDL's eerste boeking is om 09:39 gemaakt, wat dus ná de hangtijd van MH is.

JAS journaliseerde om 09:58 voor het eerst n.a.v. een handmatige Voorraadmutatie.

LV heeft om 08:19 een bankafschrift geboekt en daarna om 09:56 een Ingekomen Faktuur of Faktuurgekontrole geboekt.

Dat zou dus moeten inhouden dat er niemand anders aan het journaliseren is geweest toen MH ging omvormen.

Met de nieuw logfile moeten we weer even "de volgende keer" afwachten, dan komen we wellicht weer een stukje verder...

Aanvullend wat ik gezien heb:
Ik heb achter het scherm gezeten toen de melding 'Record not available' in beeld stond.
Na ons gesprek eerst LV gevraagd Profit vrij te geven en af te sluiten. De melding bleef staan.
Daarna DdL gevraagd vrij te geven en af te sluiten, melding bleef nog steeds staan.

Vervolgens gebruiker PB Profit afgesloten, toen ik terugliep naar de pc was de melding verdwenen.
Kun je zien of hij er iets mee te maken kan hebben? Of is dit een gevalletje toeval? Want een andere gebruiker heeft wellicht de record tegelijk vrijgegeven ofzo, maar misschien zie je bij gebruiker PB nog iets wat opvalt.

Hey, goed van je dat je daar op hebt gelet.

Ik zou nu nog even niet kunnen verzinnen wat de link moet zijn.
PB was in ieder geval niet aan het journaliseren, en ook niet aan het Omvormen. Zijn laatste omvorming was gistermiddag.

Vandaag is er weer een nieuwe situatie gemeld. Ik zie ook dat in dit topic de laatste situatie uit december 2018 dateert, terwijl we hier wat mij betreft later nogmaals naar hebben gekeken, en met eenzelfde resultaat als nu: De logfile toont op zich nu de plek waar het precies fout gaat. Eigenlijk een normale opdracht om een Record te locken (RLOCK()) waar hij 5 minuten op staat te wachten.

Tsja... we weten nu dus welk commando dit veroorzaakt, nu nog zien te beoordelen 'waarom dat commando tot deze fout leidt'?
Ik zou het zelf even niet weten  :(

--------------------------------------------------------------------------------
01-03-2019/10:17:02.78 Bedrijf = BBB-BETON; User = MH ; Artikel HAL8ZWKVM; VrsVorm ST; Charge 101592; Aantal x Inhoud : 28578 x 1.000
01-03-2019/10:17:03.10 LOVIOTF1 : Doorboeken Batchboekingen
01-03-2019/10:17:03.21 ADBOTVW1 : Begin
01-03-2019/10:17:03.21 ADBOTVW1 : Journaalpost-id = LOVIOT       
01-03-2019/10:17:03.21 ADBOTVW1 : MULTILOCKS ON
01-03-2019/10:17:03.23 ADBOTVW1 : Voor aanroep ADBOTVW2
01-03-2019/10:17:03.23 ADBOTVW2 : Begin ADBOTVW2
01-03-2019/10:17:03.24 ADBOTVW2 : SYS
01-03-2019/10:17:03.24 ADBOTVW2 : Regel=1; JP Status = GOED; LOOPIND_W = D
01-03-2019/10:17:03.24 ADBOTVW2 : Batchboeking Vnr=0; Regel=1     ;Rekening=70000.0; User=MH ; Oms=OV/OG van HAL8ZWKVM/ST/ATH (28578x1,000)
01-03-2019/10:17:03.26 ADBOTVW2 : ADBOBO naar Hulpbestand
01-03-2019/10:17:03.28 ADBOTVW2 : Regel=2; JP Status = GOED; LOOPIND_W = D
01-03-2019/10:17:03.28 ADBOTVW2 : Batchboeking Vnr=0; Regel=2     ;Rekening=70000.0; User=MH ; Oms=OV/OG naar HAL8ZWKVK/ST/ATH (28578x1,000
01-03-2019/10:17:03.29 ADBOTVW2 : ADBOBO naar Hulpbestand
01-03-2019/10:17:03.29 ADBOTVW2 : Regel=3; JP Status = GOED; LOOPIND_W = D
01-03-2019/10:17:03.29 ADBOTVW2 : Regel=3; JP Status = GOED; LOOPIND_W = D
01-03-2019/10:17:03.31 ADBOTVW2 : Einde ADBOTVW2
01-03-2019/10:17:03.31 ADBOTVW1 : Terug na aanroep ADBOTVW2
01-03-2019/10:17:03.31 ADBOTVW1 : ADBOBO Hulpbestand doorboeken
01-03-2019/10:17:03.31 ADBOBO   : Doorboeken - tijd = 212418238623
01-03-2019/10:17:03.32 ADBOBO   : Doorboeken - BTW geboekt?
01-03-2019/10:17:03.34 ADBOBO   : Doorboeken #1 -    1|Grtbk|70000.0       |~             |OV/OG van HAL8ZWKVM/ST/AT
01-03-2019/10:17:03.34 ADBOBO   : Doorboeken #1 - voor APPEND BLANK
01-03-2019/10:17:03.35 ADBOBO   : Doorboeken #1 - voor RLOCK
01-03-2019/10:22:24.04 ADBOBO   : Doorboeken #1 - voor REPLACE
01-03-2019/10:22:24.20 ADBOBO   : Doorboeken #1 - na (eventueel geskipte) UNLOCK
01-03-2019/10:22:24.23 ADBOBO   : Doorboeken #1 -    2|Grtbk|~             |70000.0       |OV/OG naar HAL8ZWKVK/ST/A
01-03-2019/10:22:24.23 ADBOBO   : Doorboeken #1 - voor APPEND BLANK
01-03-2019/10:22:24.24 ADBOBO   : Doorboeken #1 - voor RLOCK
01-03-2019/10:22:24.24 ADBOBO   : Doorboeken #1 - voor REPLACE
01-03-2019/10:22:24.26 ADBOBO   : Doorboeken #1 - na (eventueel geskipte) UNLOCK
01-03-2019/10:22:24.26 ADBOBO   : Bijwerken saldo rekening 70000.0       
01-03-2019/10:22:24.27 ADBOBO   : Bijwerken saldo rekening 70000.0       
01-03-2019/10:22:24.27 ADBOTVW1 : Na doorboeken ADBOBO
01-03-2019/10:22:24.29 ADBOTVW1 : Historisch maken Batchboeking Rgl 1
01-03-2019/10:22:24.31 ADBOTVW1 : Historisch maken Batchboeking Rgl 2
01-03-2019/10:22:24.31 ADBOTVW1 : MULTILOCKS OFF
01-03-2019/10:22:24.32 ADBOTVW1 : Verwijderen Batchboeking Rgl 1
01-03-2019/10:22:24.33 ADBOTVW1 : Verwijderen Batchboeking Rgl 2
01-03-2019/10:22:24.34 ADBOTVW1 : MULTILOCKS OFF
01-03-2019/10:22:24.35 ADBOTVW1 : ZAP ADBH
01-03-2019/10:22:24.35 ADBOTVW1 : Einde ADBOTVW1
01-03-2019/10:22:24.36 ADBOTV1 : Na aanroep ADBOTVW1
01-03-2019/10:22:24.36 LOVIOTF1 : Einde Doorboeken Batchboekingen
01-03-2019/10:22:24.38 Na aanroep LOVIOTF1, terug in LOVIOT
--------------------------------------------------------------------------------

:11a:

Dank Wouter - ter info: gebruiker (user MH) heeft het gelijk gemeld waarop ik gebeld heb.
Daarna naar receptie gelopen (user LV, zit in administratie/financiele deel) en gevraagd Profit even af te sluiten. Daarna was Profit weer vrij.

Enige foutje van me - ik heb niet net voordat ik Profit heb laten afsluiten gekeken of Profit alweer vrij was bij MH.
Maar na afsluiten van Profit door LV in elk geval wel.

Ik krijg in een andere funktie ook een 'Record not available', namelijk bij het boeken van een termijnboeking bij gebruiker LV.

Wist even niet of ik hier een apart topic voor moest aanmaken, maar gezien het verhaal mbt logfiles etc - wellicht kun je daar ook deze in opsporen?
Profit is afgesloten en opnieuw gestart.
Misschien helpt dit het probleem bij Omvormen artikel (of juist helemaal niet).
Wanneer ik toch even een nieuw topic aan moet maken hoor ik het graag.

Heb je rond de tijdstippen van zo'n melding al wel eens in een error logfile op de Server gekeken?
Kan het zijn dat je daarin fouten aantreft die kunnen duiden op wat er aan de hand is?

Ik heb hiernaar gekeken (logs rond het tijdstip van de meldingen uiteraard) en niks bijzonders kunnen vinden op Terminal server of de server waar Profit op draait.
De dataserver geeft wel af en toe aan dat RAM vol zit, maar op moment van kijken was dit niet zo.
Toch ga ik daar het RAM geheugen uitbreiden om te kijken of de melding verdwijnt (en baat het niet dan schaadt het niet uiteraard).

Ter info - vandaag kreeg gebruiker RN bij het omvormen de 'Record not available' melding.
Om 15:27 stond deze al een aantal minuten op het scherm.
Gebruiker LV zat ingelogd bij de receptie, waar een oudere pc staat - alleen wanneer ze daarop ingelogd is lijkt het nog fout te gaan.
Ze staat op de nominatie voor een nieuwe pc, als het meezit binnen 2/3 weken. Zoals al eerder door jullie opgemerkt zou het aan die (oude, trage) pc kunnen liggen.

Is het een idee dat ik me meld wanneer ik deze pc vervangen heb en daarna alsnog de foutmelding krijg (?).

Altijd. Wat is trouwens "een oudere PC". Heb je specifikaties voor de herkenbaarheid?

Zeker, het is een HP Compaq Pro 6300 SFF
Met een Intel I5-3470 CPU @3.20Ghz,  4Gb intern en Windows 7 Pro 64-bits, aangeschaft in 2013.