Heart-Profit ERP

Waar meerdere gebruikers bij ons de laatste tijd regelmatig last van hebben is het volgende:
Na het afsluiten van Profit verschijnt een klein schermpje met een 'Manual error'. Wanneer je hierop klikt krijg je er soms nog 1.
Soms komt hierna nog onderstaande foutmelding in beeld.

Enig idee wat dit veroorzaakt? Wanneer ik de schermpjes met de 'Manual error' te zien krijg zal ik die posten alsook hetgeen de gebruikers als laatst in Profit gedaan hebben voordat ze eruit gingen. Maar misschien zegt dit verhaal jullie al iets?
:17c:

Pascal, jullie laatste upgrade is van 4 juni, en de één na laatste is van 14 mei;
Wat wij niet kunnen zien, is wanneer jullie welke versie van Test naar Produktie overzetten. Aldus graag een indikatie van

a. sinds wanneer je dit (in Produktie) hebt
b. sinds wanneer je met welke bovengenoemde "datum"versies in Produktie werkt.

a. weet ik niet precies, maar minimaal een week. Of het voor 6 juni cq 4 juni ook al gebeurde durf ik niet te zeggen. Daarbij moet je er maar op vertrouwen dat dit altijd gemeld wordt (is wel de bedoeling, maar goed daar heb ik geen 100% controle over).
b. upgrade van 14 mei is 30 mei overgezet (wegens omstandigheden, ik weet dat dit bij voorkeur binnen een week moet)
upgrade van 4 juni is 6 juni overgezet

Inmiddels heb ik de fout nog een keer gezien - dit keer wel schermafdrukjes van de Manual error.
Eerst krijg je de 1e te zien, wanneer je vervolgens een keer klikt met de linkermuisknop krijg je de 2e te zien. Daarna zie je het scherm v/d Resource Manager.

De gebruiker weet nog dattie Verkooporders heeft geraadpleegd en daarna Profit heeft afgesloten.

Het is (denk ik) niet van levensbelang, maar weet die gebruiker nog wat hij/zij deed na dat Raadlegen Verkooporders ? Ik bedoel, F10 en klikken op stop. Ctrl-s, geen F10 maar Esc-Esc-Esc enz. ?

Even nagevraagd: na het raadplegen van de verkooporders via ESC-ESC-ESC tot in het hoofdmenu. Vervolgens klikken op de rode pijl om Profit af te sluiten. Meteen daarna kwamen de meldingen.

In de melding staat iets over een JXBEDRAG_S.Destroy. Er is één funktiedeel waar JXBEDRAG_S als variabele gebruikt wordt, en dat is de journaliseringsmodule.

Maar ja... Toevoegen of Raadplegen Verkooporders, danwel Esc, Esc, Esc tot in het Hoofdmenu journaliseert helemaal niets.

Hoe zeker is dat het antwoord op hetgeen nagevraagd is klopt?

Doen jullie misschien toch iets met journalisering vanuit een Verkooporder ? (desnoods 1:1 een Inkoopordergenereren, en dat gekombineerd met het journaliseren van Inkoopverplichtingen of i.d.)?

Kan het zijn dat de betreffende persoon vóórdat hij bij raadplegen VO's en esc, esc, esc eerst iets anders gedaan heeft met journalisering wat fout is gelopen of i.d.?

Gebruiker heeft wel voordat-ie de Verkooporders geraadpleegd heeft nog 3-3-1-1, SHIFT-F7 Raadplegen Journaalpost gedaan, om te checken wie een factuur gemaakt heeft (deze gebruiker faktureert ook).

Ik kan me alleen wel voorstellen dat de gebruiker dat er niet bij vermeldt, omdat je normaal gesproken je laatste handelingen doorgeeft voordat er iets fout gaat.

Opvragen (Raadplegen) is niet voldoende; het zou echt journaliseren moeten zijn geweest.

Ben zojuist ben jullie ingelogged, start Profit op, en krijg een andere foutmelding (zie bijlage) die je eigenlijk helemaal niet behoort te kunnen krijgen. Misschien zijn er wel andere vreemde dingen aan de hand. Ik kijk ondertussen nog even verder.

Gisteren rond 16:55 hebben we een stroomstoring gehad.
Volgens mij stond er ook nog een sessie van jullie open.

Ik denk dat ik al wel iets gevonden heb. Nu nog even zien te verklaren hoe je dat voor elkaar gekregen hebt.

Mijn JXBEDRAG_S = Journalisering klopt toch wel redelijk...

13 juni, om 11:09:06 krijgt DDL een melding vanuit de Journalisering:

(http://www.heartprofit.com/www/transfer/graphics/forum/syerrawx070614001.png)

9 seconden later, 11:09:15 volgt er een tweede melding:

(http://www.heartprofit.com/www/transfer/graphics/forum/syerrawx070614002.png)

Uit de stack haal ik vervolgens dat ADBOTVW2 direkt vanuit het Hoofdmenu LO werd aangeroepen, waarbij ik zo 1,2,3 nog even niet zou weten hoe, maar "juist" is dat niet, en daarvan zal hij ook vast wel in de war raken.

Klopt het dat DDL die gebruiker was? Zo ja, dan heeft hij eerst 2 geblokkeerde funkties gehad voor hij eruit knalde.
Uit de eerste melding haal ik dat hij via het menu naar journalisering is gegaan, en daar iets met een userbutton heeft uitgehaald. Wie hoe wat waarnaartoe weet ik niet, maar dat kan hij zich misschien nog wel herinneren.

In theorie kan het ook nog te maken hebben met hoe de vraag "Sorry gevraagde funktie is geblokkeerd" is beantwoord. Daar zit tegenwoordig een "Reset" toets bij, welke terugkeert naar het hoofdmenu, zonder alles te resetten, en waarbij de kans op nog een fout het grootst is.

Hoe dan ook, gebruiker DDL moet zich maar even proberen te herinneren wat hij precies gedaan heeft.

Pascal, klopt dit wel, met de nadruk op "meerdere" ?

Meerdere: users WAR, LV, LH (degene waar bovenstaande schermen betrekking op hebben) en DdL hebben sowieso de Manual error wel eens gehad bij het afsluiten van Profit.

WAR meldt me nu net de volgende melding, ook een fout in Journalisering: hij doet menu 7-1-3 en krijgt de melding.

Dit zal te maken kunnen hebben met je stroomstoring. De gebruiker moet hier eerst even TBC reorganiseren, en als dat niet helpt, zal er een bestand op het netwerk gereorganiseerd moeten worden. Een melding als deze kun je in principe altijd al zelf veroorzaken (zomaar je pc uitzetten), en heeft op zich niets met de andere melding te maken.

Nou, ik vind het anders een nogal "harde" melding. Niet dat zo'n melding (d.w.z. buiten de error-trap om) niet kan voorkomen, maar hier staan er in 1 topic al 3 op een rij ...

Volgens mij loopt deze melding wel vaker op deze manier fout, en ik denk dat je dit ook zo na kunt spelen.
Bij aanroep van de funktie wordt aangegeven dat die tabel nodig is, via de SELECT blijkt dat de tabel nog niet geopend is, en via de error-trap wordt ze geopend, en tijdens het openen (errortrap is al aktief) blijkt dat de records niet overeenkomen met wat er in de index staat.

Herhalen van wat ik zelf zeg is niet nodig, net zo min als duidelijk maken wat ik zelf heb ontwikkeld, ooit.
Nu die andere 2 nog.

Ter aanvulling: ook gebruiker GTH krijgt een Manual error, in dit geval nadat hij doet:
menu 2-1-1-1 SHIFT-F4 raadplegen Kontaktpersonen Relatie
F4 toevoegen Relatie, F1
vervolgens krijgt hij onderstaande Manual Error

Pascal,

Als ik je vertel dat jouw "manual error" niets anders is als een error die niet op de gebruikelijke manier kan worden afgehandeld, maar op zich alle soorten fouten van de wereld kan bevatten ... weet je dat het nogal snell offtopic wordt door ze allemaal bij elkaar te noemen. Nu kan jij weer niet beoordelen dat dit niets te maken heeft met de voorgaanden, terwijl die gerelateerd leken al was het maar omdat je het zelf suggereert ...

Hoe dan ook, in dit geval is jouw laatst weergegeven "fout" helemaal nergens aan gerelateerd, omdat het al eerder is foutgegaan maar de gebruiker jou dat niet heeft verteld. Hier kunnen we dus niets mee.
N.b.: "Foutgegaan" kan in deze betekenen "ik drukte op Esc en bevond me ineens op het hoofdmenu !". Dus wel iets lastiger voor een gebruiker om te herkennen.

Ok, maar hoe achterhaal ik nu nog wat er eerder fout is gegaan?
Bijvoorbeeld in het geval van de manual error die optreedt bij het afsluiten van Profit (op het moment dat je de rode pijl aanklikt): deze fout komt regelmatig voor bij meerdere gebruikers. Niet altijd, maar komt wel regelmatig terug. Het kan best zijn dat hieraan vooraf iets anders fout is gegaan, maar dat niet gemeld is, danwel niet opgevallen (zoals je al aangeeft het kan ook zijn dat dit iets geweest is als "ik drukte op Esc en bevond me ineens op het hoofdmenu !", wat niet als fout herkend is).

Dit kan ik dus niet meer achterhalen maar ik zit wel met die manual errors. Wat moet ik nu doen om dit op te lossen?

Uhhmm ... Ik heb niet geprobeerd te zeggen dat het nutteloos is zo'n "manual" fout te melden, maar hooguit dat ze niet allen op één  stapel in één topic terecht dienen te komen. Dit gekombineerd met de toevalligheid dat de laatste fout die je noemt een afgeleide is van een andere. Dat geldt dus voor die fout, en voor maar weinig anderen.

Merk op dat de laatstgenoemde fout aangeeft dat de "desktop" van Profit er niet meer is. Dat kun je ook zo zien (als het gebeurt) want je buttons (funktietoetsen) en alles zijn er niet meer.
Dit kun je met rare (lees : door ons onverwachte) handelingen wel voor elkaar krijgen, maar zal ook kunnen gebeuren als er tijdens de afhandeling van een fout op zich iets fout gaat. Het systeem krijgt het dan niet meer goed, en al heel snel moet er iets gebeuren met de "desktop" (dat is die frmtop die je in de melding ziet).

Als je in Windows, zonder Explorer opgestart te hebben, explorer.exe eruit gooit, krijg je net zo'n effekt. Het systeem kan zelf niets meer, en jij kan ook niets meer. Eigenlijk gaat alles fout (en de desktop is nog weg ook).

Let wel Pascal, wat dus wel aan de orde kan zijn is "iets" in de afhandeling van fouten, zoals wellicht geïndiceerd in de eerste posts van dit topic. Ik kan niet bedenken wat dat kan zijn, althans niet zonder verdere mededeling / melding van de gebruikers. Het is ook van nergens herkenbaar (wat niet zegt dat het niet kan bestaan).
Die laatste fout heef er echter niets mee te maken. Da's gewoon toeval (hoogstwaarschijnlijk dan).

Omdat er meerdere mensen meelezen, zijn we nu ineens wel zo ver dat het herkenbaar is dat jij niet de enige bent waar dit (zie begin topic) "sinds kort" gebeurt.

Het lijkt op een Visual FoxPro fout, die echter heus ineens door ons wordt uitgelokt.

We gaan op zoek ...

VFP fout lijkt het inderdaad op, alleen ik denk niet door ons uitgelokt.

Al eerder konstateerden we problemen m.b.t. een Spinner control in kombinatie met het gebruik van F1 in zo'n control (http://ha1.heartprofit.nl/profit/index.php?topic=16916.msg17067#msg17067). De manuele error is eveneens reproduceerbaar in situaties waarbij F1 gebruikt wordt in een Spinner control.

In een eerdere printscreen ging e.e.a. fout op een JXBEDRAG_S.Destroy  en we hebben ook voorbeelden vanuit Dagboekjournalisering m.b.t. VVBEDRAG_S.Destroy; beide Spinner controls.

De Resource Manager Internal Consistency Error heb ik niet weten te reproduceren, maar kan een gevolg zijn van bovenstaande.

Hetgeen in de .Destroy() fout gaat is nu omzeild, waardoor de Manuele Error niet meer optreedt (zit in Classkoding en vereist een Upgrade). Dit neemt echter niet weg dat de .Destroy() van het Spinner veld al had moeten optreden bij het verlaten van het Form, en niet bij het afsluiten van Profit.
In theorie kan er dus nog steeds een error optreden; dit zullen we even moeten afwachten.